Like Tree1Likes
  • 1 Post By memcpy

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

  1. #1
    Registered User
    Join Date
    Apr 2010
    Location
    Vancouver
    Posts
    127

    Best practices when coding

    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.

  2. #2
    Registered User
    Join Date
    Dec 2011
    Posts
    795
    > 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.
    MK27 likes this.

  3. #3
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,269
    Quote Originally Posted by c_weed
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,273
    Quote Originally Posted by laserlight View Post
    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.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #6
    Registered User
    Join Date
    Apr 2010
    Location
    Vancouver
    Posts
    127
    Quote Originally Posted by memcpy View Post
    > 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
    I had this
    Code:
    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?

  7. #7
    Registered User
    Join Date
    Sep 2007
    Posts
    131
    Not really. Not with assembly. Assembly is a different beast apart from any higher level language. In your example, it would be best as:

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

  8. #8
    Registered User
    Join Date
    Apr 2012
    Posts
    44
    It all involves the preferences of those who are marking.

  9. #9
    Registered User
    Join Date
    Dec 2011
    Posts
    795
    Quote Originally Posted by TexasKid View Post
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. getchar() best practices
    By albundy in forum C Programming
    Replies: 2
    Last Post: 09-03-2011, 06:55 AM
  2. Replies: 18
    Last Post: 05-06-2011, 08:22 PM
  3. Best Practices For Includes
    By valaris in forum C++ Programming
    Replies: 13
    Last Post: 03-09-2009, 04:12 AM
  4. coding practices
    By pobri19 in forum C++ Programming
    Replies: 2
    Last Post: 07-17-2008, 05:56 PM
  5. deque best practices
    By George2 in forum C++ Programming
    Replies: 10
    Last Post: 03-02-2008, 08:11 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21