Thread: Horribly Formatted Code??

  1. #1
    Registered User
    Join Date
    Oct 2015
    Posts
    42

    Horribly Formatted Code??

    I was wondering if anyone could tell me what is a horribly formatted code and what are "well" formatted codes supposed to look like? What would make someone say the program is horribly formatted? Besides problems with indentation and whitespace.

  2. #2
    Registered User taazz's Avatar
    Join Date
    May 2016
    Posts
    50
    Quote Originally Posted by nadeera View Post
    I was wondering if anyone could tell me what is a horribly formatted code and what are "well" formatted codes supposed to look like? What would make someone say the program is horribly formatted? Besides problems with indentation and whitespace.
    indentation and white space is THE formating there is nothing left if you remove those. In general we say that a piece code has good formatting when it has persistent formatting, the indentation is persistent across the board not different indentation for if, other for case and yet an other for loops etc. There is are two small rules I always follow as well but has nothing to do with formatting it has to do with readable code.
    1) Never use oddities in your code that hide the intention of the programmer for example I consider i++ a bad practise (but it is so widely used that it makes no real difference) I prefer the more plain i = i + 1 or inc(i) or something along those lines it makes things clear for debugging (especially when you are not the debugger). 2) never put two commands in one line.

  3. #3
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,237
    Quote Originally Posted by nadeera
    What would make someone say the program is horribly formatted? Besides problems with indentation and whitespace.
    As taazz pointed out, indentation (and with indentation, how statements are placed, such as taazz's "never put two commands in one line" advice) and whitespace (and with whitespace, when to use blank lines) is really what formatting is about, and the key to this is to be reasonably consistent, e.g., follow the existing formatting for source code written by someone else, or for new code follow the team's formatting conventions, or your own consistent formatting rules. Formatting is just one part of style, which can encompass things like when to split functions into smaller functions, how to organise the code with the help of structs, the use of named constants, etc.

    Quote Originally Posted by nadeera
    I was wondering if anyone could tell me what is a horribly formatted code and what are "well" formatted codes supposed to look like?
    Looking around, I found this thread on Length of an array. Compare the code that papyka posted with the revised version that CodeSlapper posted. You will find that it is easier to trace the flow of control in CodeSlapper's version (e.g., where does which loop start/stop?) because the logical structure of the code is more clearly expressed with the help of indentation.

    Quote Originally Posted by taazz
    Never use oddities in your code that hide the intention of the programmer for example I consider i++ a bad practise (but it is so widely used that it makes no real difference) I prefer the more plain i = i + 1 or inc(i) or something along those lines it makes things clear for debugging (especially when you are not the debugger).
    I agree with the general sentiment, but I disagree with the specific example: i++ expresses the intention of the programmer clearly where it is used standalone such as in a typical incrementing for loop. In this usage, it is equivalent to and even better than inc(i), since inc is non-standard and not very descriptively named (it probably means "increment", but better check, and you might have to write inc(&i) instead).
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #4
    Registered User
    Join Date
    Jul 2016
    Location
    Holloway
    Posts
    2
    Here's an example of what could be when Java meets Python. This one is definitely horrible formatted one. Java meets Python: At least the programmer did not write: self.getRepo() - Imgur

  5. #5
    Registered User rstanley's Avatar
    Join Date
    Jun 2014
    Location
    New York, NY
    Posts
    678
    Take a look at the article on source code indenting styles on Wikipedia. Pick one style and stick with it.

    A good programmers editor such as emacs, or vi/vim, will have features that will automatically indent your code for you as you write. These editors will let you choose what style you wish to use.

    If you are using a different editor, or an IDE, (Integrated Development Environment) please look a the documentation to see if it has similar features.

  6. #6
    Its hard... But im here swgh's Avatar
    Join Date
    Apr 2005
    Location
    England
    Posts
    1,687
    Just to add, there is a debate whether to use tabs or spaces, and which
    brace placement is "standard". As others have mentioned it is all a matter
    of personal preference.

    John Cormack (Head Programmer at id Software) once quoted he disliked the
    way he formatted his code. When he changed from C to C++ (Doom 3) he
    modified his formatting style and never looked back. I wish I had a snippet of
    the code to show the comparisons but cannot find the link anymore.
    Double Helix STL

  7. #7
    Registered User rstanley's Avatar
    Join Date
    Jun 2014
    Location
    New York, NY
    Posts
    678
    Quote Originally Posted by swgh View Post
    Just to add, there is a debate whether to use tabs or spaces, and which
    brace placement is "standard". As others have mentioned it is all a matter
    of personal preference. ...
    As for the Spaces vs. Tabs controversy, it is more complicated than simple personal preference. If you use tabs and someone else maintains your code later, and uses a different number of spaces per tab, your nice formatting gets screwed up, or at least looks terrible! (ie. You use two spaces per tab, and another programmer uses 8 spaces per tab!) ;^)

    I recommend using spaces instead of tabs for all your source files, AND use a good programmers text editor.

    There is one exception to the all spaces in a file which is Makefiles. Makefiles require a tab, not spaces in front of a command. It was a design flaw in Make which was not corrected and now can never be.

    Code:
    target: dependencies
    <tab>command1
    <tab>command2
    A good programmers text editor such as emacs, which I use, will insert a tab NOT spaces where it is required, even though I use spaces by default!

  8. #8
    Registered User taazz's Avatar
    Join Date
    May 2016
    Posts
    50
    Quote Originally Posted by laserlight View Post
    I agree with the general sentiment, but I disagree with the specific example: i++ expresses the intention of the programmer clearly where it is used standalone such as in a typical incrementing for loop. In this usage, it is equivalent to and even better than inc(i), since inc is non-standard and not very descriptively named (it probably means "increment", but better check, and you might have to write inc(&i) instead).
    I agree 100% inc(i) is as bad as i++ the only difference between the two is that you are familiar with i++ and I'm familiar with inc(i).

  9. #9
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by taazz View Post
    I agree 100% inc(i) is as bad as i++ the only difference between the two is that you are familiar with i++ and I'm familiar with inc(i).
    No, the difference is that one is a well-documented, well-defined part of the language specification, whose semantics are understood by nearly all C programmers, and the other is not.
    What can this strange device be?
    When I touch it, it gives forth a sound
    It's got wires that vibrate and give music
    What can this thing be that I found?

  10. #10
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,612
    As for the Spaces vs. Tabs controversy, it is more complicated than simple personal preference. If you use tabs and someone else maintains your code later, and uses a different number of spaces per tab, your nice formatting gets screwed up, or at least looks terrible! (ie. You use two spaces per tab, and another programmer uses 8 spaces per tab!) ;^)
    No, I really don't agree. If you use tabs, then the editor will display what each person finds comfortable and save tabs to the file. Spaces are permanent, but tabs are portable. Plus, I haven't really written any program that didn't at least cope with additional spacing. It might be wider than you like, but it's not exactly Satan himself. Just don't mix tabs and spaces.

  11. #11
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,907
    I'm going to sum it up as well-formatted == easy to read and understand, poorly formatted == hard to read or understand. If you can look at a source file and it's easy to parse (separate identifiers from operators, figure out where one definition/statement/block/function ends and the next one begins) and it's easy to follow the flow (it's clear which statements are subordinate to what), then it's probably reasonably well formatted. The more different code bases I work in and the more different sets of formatting rules I'm forced to adhere to, the less I care about any specific rule (tabs vs spaces, open brace on it's own line, etc). I usually find that horribly formatted code is code with inconsistent formatting throughout a given file. Things like:

    • The spacing around operators is inconsistent.
    • There is inconsistent brace placement or inconsistent use of braces on conditionals/loops with a one-statement body.
    • They use different strategies for breaking up long lines or aligning text on sequential lines (e.g. nested initializers).
    • They use inconsistent comment markers.
    • Moderation in spacing and indentation. Many people try to cram stuff in, to fit as much as possible on one line/screen. Others have 6 blank lines between each function.


    Really, the best way is just to read lots of code. The more code you read and are exposed to, the more you'll get a feel for this stuff. You'll start to compare things mentally, and you'll think "wow, that looks neat and orderly" or "Woah, WTF is going on there?". Pay attention to what aspects of the formatting make the code seem poorly formatted or hard to read/understand.

  12. #12
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,237
    Quote Originally Posted by taazz
    I agree 100% inc(i) is as bad as i++ the only difference between the two is that you are familiar with i++ and I'm familiar with inc(i).
    I have not met a C programmer -- even a beginner a few weeks into his/her first programming language -- who is unfamiliar with i++, but until you came along, I have not met a C programmer who is familiar with inc(i). By the sheer weight of extremely strong convention, i++ is so much better than inc(i) that it isn't funny.

    Not only that, but while i = i + 1 does indeed express the increment, its form is deliberately open to expressing other things, i.e., it is a general form for addition followed by assignment, possibly to a different variable (and hence historically it may have been less efficient, though that no longer applies with modern compilers). Therefore, if you want to do a "step increment" of i, increased say by 2 instead of 1, i += 2 is superior to i = i + 2 because it expresses your intention more definitely: no possibility of a mistake with j = i + 2. Likewise, since the language permits it, for increment i++ (or equivalently ++i when standalone) is superior to i += 1 which is superior to i = i + 1 because it expresses the intention most definitely (and incidentally, most concisely).

    Furthermore, how did you implement inc? I am surprised that your example is inc(i) rather than inc(&i) or i = inc(i).
    Last edited by laserlight; 07-27-2016 at 08:38 PM.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  13. #13
    Registered User taazz's Avatar
    Join Date
    May 2016
    Posts
    50
    Quote Originally Posted by laserlight View Post
    I have not met a C programmer -- even a beginner a few weeks into his/her first programming language -- who is unfamiliar with i++, but until you came along, I have not met a C programmer who is familiar with inc(i). By the sheer weight of extremely strong convention, i++ is so much better than inc(i) that it isn't funny.

    Not only that, but while i = i + 1 does indeed express the increment, its form is deliberately open to expressing other things, i.e., it is a general form for addition followed by assignment, possibly to a different variable (and hence historically it may have been less efficient, though that no longer applies with modern compilers). Therefore, if you want to do a "step increment" of i, increased say by 2 instead of 1, i += 2 is superior to i = i + 2 because it expresses your intention more definitely: no possibility of a mistake with j = i + 2. Likewise, since the language permits it, for increment i++ (or equivalently ++i when standalone) is superior to i += 1 which is superior to i = i + 1 because it expresses the intention most definitely (and incidentally, most concisely).

    Furthermore, how did you implement inc? I am surprised that your example is inc(i) rather than inc(&i) or i = inc(i).
    No sorry. += -= /= and all that the only thing that they offer in today's compilers is backwards compatibility and possible a couple of keystrokes while coding. They are worst than i++ and in my code are avoided at all costs. I do understand that prior art makes my point mute but they are at the same the most apt example of bad habits and unintelligent design.

  14. #14
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,237
    Quote Originally Posted by taazz
    No sorry. += -= /= and all that the only thing that they offer in today's compilers is backwards compatibility and possible a couple of keystrokes while coding. They are worst than i++ and in my code are avoided at all costs. I do understand that prior art makes my point mute but they are at the same the most apt example of bad habits and unintelligent design.
    Why is it "worst than i++" and why do you call them "bad habits and unintelligent design"? What is your response to my point that they articulate intention more clearly because they are more specific?

    It would also be nice to have an answer to my question as to how did you implement inc.
    Last edited by laserlight; 07-27-2016 at 11:23 PM.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  15. #15
    Registered User taazz's Avatar
    Join Date
    May 2016
    Posts
    50
    Quote Originally Posted by laserlight View Post
    Why is it "worst than i++" and why do you call them "bad habits and unintelligent design"?
    Considering that they are a good example of bad code using them constitutes a bad habit, Unintelligent design is because in order to have those working you have to alter the compiler to recognize them in which case you should have added some intelligent optimization instead of introducing oddities like that.
    Quote Originally Posted by laserlight View Post
    What is your response to my point that they articulate intention more clearly because they are more specific?
    they are as clear as an algebraic symbol. If you know what it does its clear if you do not its not, in contrast with i = i+1 which is always clear regardless if you know c/c++ or not.
    Quote Originally Posted by laserlight View Post
    It would also be nice to have an answer to my question as to how did you implement inc.
    the first version of this function was written in asm and it was a direct call to the inc instruction instead of add with an instruction to move the incoming value to the output register the next version added some overflow checking as well. In modern compilers with better optimization it was converted to allow the compiler to optimize it and left there for compatibility reasons.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Formatted output %*s
    By dtow1 in forum C Programming
    Replies: 3
    Last Post: 12-15-2012, 12:29 PM
  2. Replies: 4
    Last Post: 04-10-2006, 05:43 PM
  3. formatted output
    By Magica in forum C Programming
    Replies: 3
    Last Post: 05-11-2003, 11:36 PM
  4. Please help with formatted I/O
    By ucme_me in forum C Programming
    Replies: 9
    Last Post: 12-07-2001, 09:10 AM
  5. formatted I/O
    By Unregistered in forum C Programming
    Replies: 0
    Last Post: 12-05-2001, 08:05 PM

Tags for this Thread