Best practices when coding

This is a discussion on Best practices when coding within the Tech Board forums, part of the Community Boards category; I just transfered from a college to university and everything I thought was good practice for coding they concider bad. ...

> indenting code (shouldn't be done in assembly)
I'm sure this is a stylistic thing that really doesn't affect anything unless your code is unclear. So marking off for not using a specific style is kind of cheap. I usually use this format:

Code:

label:
instructions
instructions
label2:
instructions
instructions

> commenting out code used for debugging instead of deleting it
This is really only valid when referring to production code. During the programming process, commenting out is almost always better than deleting in regards to functions that you don't need/developed a new way to do/etc.

> creating subroutines when not nescecary (this makes no sense to me)
I'm assuming they wanted you to inline commonly used and short functions, instead of making them subroutines. This is generally a good idea, as call/ret take many more cycles than necessary, or could be done with simple conditional jumps.

> initializing registers all to 0 at first
That's generally not necessary, because any sort of "blanket operation" that covers all registers doesn't promote thought as to why you're using those registers. Sure, it wastes a couple of cycles, but I'm guessing it's because you don't need to zero everything and doing so could be indicative of poor planning.

I think this is maybe about some of the individuals involved. IMO university departments should have clearly defined policies about this, but if they do not (which is not to say, they do not have a policy, they just have a policy with a lot of ambiguities), the door is left open for some profs and TA's to treat the first assignment as an object lesson in what they are looking for.

If I were an educator, I would make it clear what I want to see, so that when I don't see it, I can say, well, you did not do what I explicitly asked for, so here are your consequences. Which is an approach maybe most -- but not all -- educators take. If you treat assignments as object lessons, is it unfair to not explain -- even, to not explain when asked how something should be, specifically, when you do have some specific criteria in mind, but what you are judging is a student's capacity to anticipate and emulate the choices you would make?

Which is an approach maybe most -- but not all -- people would consider obnoxious and unfair. Unfortunately, it does not violate the Charter of Rights and Freedoms , lol, so your object lesson here is that you just got an object lesson, you passed (I hope) ...consider the specific things you got docked for and in the future, do no expect them to be explained. Ask: what do you want to see WRT formatting? WRT debugging? Testing? And accept that even after you ask, you may still not be able to get an unambiguous answer, if the educator has the wrong attitude, but you do not hold the power, so you must work within that reality.

I agree with your assignment marker here. This is fine while you are debugging, but once you are done, you might as well delete the commented out code. Leaving it there just clutters up the actual code and actual comments, and you can always retrieve it from version control.

I agree with your assignment marker here. This is fine while you are debugging, but once you are done, you might as well delete the commented out code. Leaving it there just clutters up the actual code and actual comments, and you can always retrieve it from version control.

If the debugging code is reasonably general-purpose, consider promoting it to "real code" status instead of discarding it. People will sometimes write complicated input/output routines to load/dump data at interesting moments, then amazingly, throw all of this work away after the bug has been squashed.

> indenting code (shouldn't be done in assembly)
I'm sure this is a stylistic thing that really doesn't affect anything unless your code is unclear. So marking off for not using a specific style is kind of cheap. I usually use this format: