OCD with coding
Generally I find the 80 character horizontal limit a waste of bandwidth archaic, so I extend it to 120 characters.
Yeah, and the C and C++ standard libraries are the biggest offenders.
etc.
The style guide for my freelance work omits braces on one-liners, and we don't have any problems with it.
The extra braces just tend to add unnecessary padding and bloat to code that are harmful to the eyes.
I don't typically use NULL statements; I find them ugly and you cannot get the gist of code quickly enough when someone is skimming. I try to use a more expressive alternative.
| Computergeek01 wrote: |
|---|
| Ambiguous variable names are my pet peeve |
|
|
| TheIdeasMan wrote: |
|---|
| I disagree, I always put braces, even if there is 1 statement, and especially even if it is a null statement (which has a comment as well). This will save you one day when you add more code. I have seen plenty of examples of those who do exactly that, and wonder why things don't work :+) |
The extra braces just tend to add unnecessary padding and bloat to code that are harmful to the eyes.
I don't typically use NULL statements; I find them ugly and you cannot get the gist of code quickly enough when someone is skimming. I try to use a more expressive alternative.
Last edited on
From the topic offending names, whoever that thought of the name "xor_eq" doesn't know what they were thinking.
| From the topic offending names, whoever that thought of the name "xor_eq" doesn't know what they were thinking. |
What's wrong with that? The name describes exactly what it does
^=| http://en.cppreference.com/w/cpp/language/operator_alternative |
Last edited on
| Apple's goto fail comes to mind. |
I used to omit braces for one liners until this huge screw up. Now I always use braces. I personally do not recall leaving out the braces ever causing me a problem/bug. I'm not saying I'm so good it could never happen to me. Things could happen, for example, you could be pushed too hard trying to meet a deadline and miss sleep for a few days, or "be out of it" for some other reason.
But it's not just yourself you might be relying on, most serious code bases will be worked on at some point by more than one person, and you may not know who. You can't trust strangers, "strangers have a bad reputation" -- Seinfeld. So I figure, it's more pragmatic to just add the braces as it arguably can make it just a little more difficult for a person to screw up. And this kind of screw up can be problematic, and hard to trace, and as in apples case, a huge disastrous security vulnerability.
Last edited on
My #1 pet peeve is poor comments or missing comments. In real world programming there will always be someone else who needs to read and understand your code. Good comments make the difference between immediately understanding and hours of puzzling.
Good comments explain why you're doing something. If a particular algorithm isn't obvious they might also explain how you're doing it.
Comments that explain what you're doing usually aren't helpful: the code says what it's doing. For example
An exception to this rule is for beginners who are still learning the syntax.
Good comments explain why you're doing something. If a particular algorithm isn't obvious they might also explain how you're doing it.
Comments that explain what you're doing usually aren't helpful: the code says what it's doing. For example
|
|
An exception to this rule is for beginners who are still learning the syntax.
| I used to omit braces for one liners until this huge screw up. Now I always use braces. I personally do not recall leaving out the braces ever causing me a problem/bug. |
In literally every job I've had, I've had this discussion with someone that doesn't believe it causes a problem. On every single occasion, I've subsequently gone on to find an existing bug in the codebase that was caused by this.
I'm not dogmatic about many things in programming, but I'm near as dammit religious about this: if you omit braces from single-line code blocks, one day, someone will add another line to one of your blocks and forget to add braces.
These days, with many people developing in both Python and C++, I suspect it's going to be more likely, because we'll get used to seeing code blocks defined by indentation without braces, and we'll be less likely to immediately spot it as a mistake in C++.
no @TheIdeasMan, do you really think that you would know what xor_eq would mean as a beginner just learning c++, I mean look at keywords like
and, its a little (a lot!) more obvious what that means
This.
instead of this
Lined up brackets is a lot clearer to read than staggered ones. Java does this constantly and it seems like its just Java style.
|
|
instead of this
|
|
Lined up brackets is a lot clearer to read than staggered ones. Java does this constantly and it seems like its just Java style.
| Computergeek01 wrote: |
|---|
| That, and macros that aren't all in caps |
There are surprisingly many of those in the standard library, by the way, from assert to stdout to PRId64 to L_tmpnam.. This could work as a bar bet next cppcon.
| Lined up brackets is a lot clearer to read than staggered ones. Java does this constantly and it seems like its just Java style. |
The story I've heard many times is that when K & R originally wrote their book, they used the convention that you and I both prefer:
|
|
However, their publisher suggested the other convention, on the basis that it would save many lines of text throughout the book, meaning the book would require fewer pages to print, and would therefore be cheaper to print.
Hence, they changed the brace style to what has become known as "K & R style".
So there you go - a sensible convention abandoned for a shitty one (*), all so that a publisher could save money.
I've also seen it referred to as "Egyptian style", which I kinda like:
http://blog.codinghorror.com/new-programming-jargon/
(*) Any opinions expressed in this post are those of the poster alone. Oh, and also of any right-thinking coder :P
While I do agree that lined up braces are better for functions, I hate them for ifs and loops because ifs and loops are much more common and get nested and it wastes so much space and means you can fit less on the screen. I believe this style is the Stroustrup style, but I can't remember for definite.
Ya know what I hate when people put their main function at the bottom...bothers me so much. Is that even necessary in some programs?
> I'm not dogmatic about many things in programming, but I'm near as dammit religious about this:
> if you omit braces from single-line code blocks, one day, someone will add another line
> to one of your blocks and forget to add braces.
>> Any opinions expressed in this post are those of the poster alone. Oh, and also of any right-thinking coder
There are a very large number of right-thinking programmers who like programming in Python.
These are the staples of writing robust code:
1. Use available tools intelligently: an editor that auto-indents, or run the code through a code formatter like A-style before it is reviewed.
2. Invest in code reviews.
3. Test the code.
Rely on these, rather than trying to memorise and adhere to a set of silly rules. There is no silver bullet.
> if you omit braces from single-line code blocks, one day, someone will add another line
> to one of your blocks and forget to add braces.
>> Any opinions expressed in this post are those of the poster alone. Oh, and also of any right-thinking coder
There are a very large number of right-thinking programmers who like programming in Python.
These are the staples of writing robust code:
1. Use available tools intelligently: an editor that auto-indents, or run the code through a code formatter like A-style before it is reviewed.
2. Invest in code reviews.
3. Test the code.
Rely on these, rather than trying to memorise and adhere to a set of silly rules. There is no silver bullet.
| RUNNER PRO AGARIO wrote: |
|---|
| no @TheIdeasMan, do you really think that you would know what xor_eq would mean as a beginner just learning c++, I mean look at keywords like and, its a little (a lot!) more obvious what that means |
I think that possibly the problem is that you know what
and means, but don't know about xor. If you did know what xor means then it's not a huge leap to understand xor_eq. Besides, what would your proposal be?
| RUNNER PRO AGARIO wrote: |
|---|
| .... whoever that thought of the name "xor_eq" doesn't know what they were thinking. |
I put it to you that: those who cause new things to be added to C++, very much know what they are thinking; it's you that doesn't understand.
Finally, there is a thing called Google: a simple search of C++ xor_eq provides the answer.
Back to the main discussion with something no one else has said yet, have I ever mentioned
using namespace std; ? I just wish that authors, lecturers, websites, examples in Boost documentation and even Stroustrup himself would quit doing that. I know it often doesn't matter for trivial homework assignments, but why can't beginners be put on the right track from the start? Could an explanation of namespaces be made along with "Hello World" ? Or is that too hard / off-putting ?
Regarding where to put the braces, I look at it like this: the braces are there for the compiler to know the block structure of the program. We humans derive the block structure from the indentation. Put another way, the braces are a necessary evil for the compiler's benefit.
With this in mind, imagine that C++ didn't use braces and instead derived the block structure from indentation. Would you write this:
or this:
?
I'd prefer the latter, or something close to it. That's why I actually write it as
rather than
If a one-liner is really trivial then I'll omit the braces but put the statement on the same line:
But this is all largely personal taste and you can burn up a lot of time and morale by trying to legislate how people format their code. So as others have said, it's best to just encourage people to be consistent.
One more thing that I haven't seen in the thread: when I need to look over someone else's code, I usually run it though a formatting program to put it into the format that I like. This way I don't have to worry about deciphering block structure. When I correct someone's code here and repost it, you'll find that it's almost always reformatted to my preferred style. There's a more sinister reason for this also: if someone simply copies and pastes my corrected code into their homework assignment, it probably won't match the style of their other work. The prof is likely to notice that right away and question whether the student did the work themselves.
With this in mind, imagine that C++ didn't use braces and instead derived the block structure from indentation. Would you write this:
|
|
or this:
|
|
I'd prefer the latter, or something close to it. That's why I actually write it as
|
|
rather than
|
|
If a one-liner is really trivial then I'll omit the braces but put the statement on the same line:
|
|
But this is all largely personal taste and you can burn up a lot of time and morale by trying to legislate how people format their code. So as others have said, it's best to just encourage people to be consistent.
One more thing that I haven't seen in the thread: when I need to look over someone else's code, I usually run it though a formatting program to put it into the format that I like. This way I don't have to worry about deciphering block structure. When I correct someone's code here and repost it, you'll find that it's almost always reformatted to my preferred style. There's a more sinister reason for this also: if someone simply copies and pastes my corrected code into their homework assignment, it probably won't match the style of their other work. The prof is likely to notice that right away and question whether the student did the work themselves.
| JLBorges wrote: |
|---|
| >> Any opinions expressed in this post are those of the poster alone. Oh, and also of any right-thinking coder There are a very large number of right-thinking programmers who like programming in Python. |
Well, quite. As I myself acknowledged in a part of my post that you omitted from you quote.
It's also worth noting that in my OP, there was an emoticon at the end of that sentence, that gave some indication of the spirit in which it was meant. Omitting that emoticon from the quote gives rather a misleading impression.
Last edited on
In function argument declarations I prefer the following:
- Use const to help indicate what is an input and what is an output
- Split arguments onto separate lines and align the const, type, reference/pointer, and name
This makes it much easier to understand how to use a function - the alignment is mostly useful when quickly skimming through someone else's code.
- Use const to help indicate what is an input and what is an output
- Split arguments onto separate lines and align the const, type, reference/pointer, and name
This makes it much easier to understand how to use a function - the alignment is mostly useful when quickly skimming through someone else's code.
|
|
The problem I find with doing that is that my formatter (AStyle), which I use to make sure that I haven't messed things up, changes that and gets rid of my lining up of things. Happens especially in classes when I line up the member variables with each on their own line. I've no idea how to get around it, so I tend to avoid trying to do that.
ja i got to have my arguments and commas like so:
I started c++ like this :
but now everythign's got to be:
also try and cat statement's have to always be
this is because of Java tutorials, weird though I cant bare to use the other one for C++ but it would actually make looking at code at uni faster.
I find it makes commenting annoying though which I have to do, I also got to leave two spaces after a constructor or an inline class.
I think I got loads of thesse but code has to look right, its paid off recently with java, my group work is easy for my group to read and use, they said it was 'sick' which is actually a real life compliment, im glad no one was saying that shit when I was a chef.
|
|
I started c++ like this :
|
|
but now everythign's got to be:
|
|
also try and cat statement's have to always be
|
|
this is because of Java tutorials, weird though I cant bare to use the other one for C++ but it would actually make looking at code at uni faster.
I find it makes commenting annoying though which I have to do, I also got to leave two spaces after a constructor or an inline class.
I think I got loads of thesse but code has to look right, its paid off recently with java, my group work is easy for my group to read and use, they said it was 'sick' which is actually a real life compliment, im glad no one was saying that shit when I was a chef.
Last edited on
+1 Norm Gunderson
I do that too, it's especially useful for ctors with init lists.
@shadowmouse
I don't have trouble with auto formatters after the fact because I don't do it :+). I am usually happy with the formatting style that my editor does as I go along. It doesn't line things like that up, I do that as I go. My editor does line up braces and does indenting, as anyone might imagine that's pretty standard.
If you like a particular style (AStyle), can't you set that in your editor, to format as you go? In QtCreator, I can choose a style, or make my own one based on an existing one. I can do the same in KDevelop.
Regards :+)
I do that too, it's especially useful for ctors with init lists.
@shadowmouse
I don't have trouble with auto formatters after the fact because I don't do it :+). I am usually happy with the formatting style that my editor does as I go along. It doesn't line things like that up, I do that as I go. My editor does line up braces and does indenting, as anyone might imagine that's pretty standard.
If you like a particular style (AStyle), can't you set that in your editor, to format as you go? In QtCreator, I can choose a style, or make my own one based on an existing one. I can do the same in KDevelop.
Regards :+)