Best practices when coding

[c_weed]

I just transfered from a college to university and everything I thought was good practice for coding they concider bad. I lost marks for the following:

• indenting code (shouldn't be done in assembly)
• commenting out code used for debugging instead of deleting it
• creating subroutines when not nescecary (this makes no sense to me)
• initializing registers all to 0 at first

I can see some reasoning to this but the fact I lost marks, especially when not told otherwise, really anoys me.

[memcpy]

> 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:

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.

[MK27]

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.

[laserlight]

commenting out code used for debugging instead of deleting it

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.

[brewbuck]

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.

[c_weed]

> 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:

label: 
    instructions
    instructions

label2:
    instructions
    instructions

I had this

label: 
    instructions
    instructions
    branch-if-equal anotherLabel
            instruction
            instruction
    anotherLabel:
    instructions

label2:
    instructions
    instructions
    branch-if-not-equal anotherLabel2
            instruction
            instruction
    anotherLabel2:
    instructions

Why is this frowned uppon in assembly, doesn't it increase redability?

[Cynic]

Not really. Not with assembly. Assembly is a different beast apart from any higher level language. In your example, it would be best as:

label:
    instructions
    instructions
    branch-if-equal anotherLabel
    instruction
    instruction

anotherLabel:
    instructions
 
label2:
    instructions
    instructions
    branch-if-not-equal anotherLabel2
    instruction
    instruction

anotherLabel2:
    instructions

And would put a blank line before labels to separate the blocks of code, but you would need to clear that with your department.

[TexasKid]

It all involves the preferences of those who are marking.

[memcpy]

It all involves the preferences of those who are marking.

Don't bump 2-3 week old threads, especially if your post's contents have already been mentioned.