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.
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.
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.Originally Posted by nadeera
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.Originally Posted by nadeera
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).Originally Posted by taazz
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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
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.
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
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.
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!Code:target: dependencies <tab>command1 <tab>command2
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?
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.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'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.
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.Originally Posted by taazz
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.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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?Originally Posted by taazz
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.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.
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.
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.