Unless the objective of the exercise is to copy an implementation (say from Java to C++), the "similarity" to any other implementation should have no weight in the grading. At least not in a positive sense. The similarity to another implementation could, however, be a warning sign for plagiarism. Everything else in the question is up for debate, so to speak.
The "fairness" of the grading only hangs on two principles: Consistent application of standards and advance notice of those standards. If the same standard, or evaluation, is applied to all the work received, and the assigned grade would be the same regardless of which student turned it in, or which TA assigned the grade, then the standards are applied consistently. Prior to the examination, or assignment, the students need to be informed as to how their work will be evaluated. In the course syllabus, or in the beginning of the course is the best time to inform them, of course. If they have been given such a notice, and then their work is evaluated according to that guide, there should be nothing to object to - from a "fairness" point of view. Knowing that there will be unit tests, even without knowing what those might be, is still acceptable, so long as the same unit tests are applied in a uniform manner to all the work evaluated.
How "fair" the evaluations are, however, likely has very small significance to how well the evaluations move the students toward the course objectives. Likewise, how such projects would be evaluated in a real-world workplace environment likely does not move them in the direction of meeting the course objectives. Of course, if the class is the final course in a series, the objective of which is to produce work-ready employees, then a purely external view of works vs. fails might be appropriate. In all other cases, however, such an extreme approach is not a very pedagogical approach. (As a side note, a binary go/no-go grade does not fit well into a scaled grading system either.)
In an idealized world, the student projects are a chance for the instructor to determine how well the student has apprehended the course materials thus far, discover where the student has stumbled, and take corrective measures to return the student to where they should be relative to the course materials. Teachers, of every stripe, are an over-worked, under-paid, unappreciated lot. (The TA's get to share in that "glory", and will become just as over-worked as the instructors.) As such many of the opportunities to learn about the difficulties and misunderstandings the students have will be missed when grading assignments. Having a rubric, published by preference, which the TA can apply to the evaluation often helps.
The course objectives, naturally, have greater weight in the rubric than other criteria. Yet non-course objectives should be included. While seldom included in the course specifications, clean code, naming conventions, documentation or self-documenting code, and adherence to coding style can all be covered by the rubric, and encouraged, thereby, in the students' work. Requiring adherence to such guidelines benefits the instructor (and TA's) in applying fine-grained grading evaluations. It can also aid the students in completing the projects, obtaining better results from the code, ease the burden of debugging the code prior to submission, and developing good habits for when they do enter the workforce, where go/no-go evaluations really matter. (I prefer to give more points to a clean almost-working program, than to a impenetrable kludge that passes every known test. The former can be maintained, including fixing the current version. The latter can probably only be maintained after being re-coded in some understandable manner.)
Unfortunately, my view is only one way of seeing the job of "instructor." As to it is okay to grade programming assignments based on this external view, the answer is; "While it is less than ideal, yes, it is okay to do so."
