Earlier quoted context omitted.
That was my way of thinking as I was junior programming.
And now...?
They're a manager and send out daily emails reminding the coders of arbitrary deadlines.
C Style: My favorite C programming practices (2014)
91–100 of 139 posts
Re: C Style: My favorite C programming practices (2014)
#92Earlier quoted context omitted.
> This 80 character limit stems from a time where terminals could only display comparatively few characters in a line, a limit we haven't had in decades as screen resolutions grew. The 80 char rule has little to do with old monitors. Has to do with ergonomics, and is why any good edited and typeset book will have between 60 and 80 characters per line.
It is a fair point, but a book is 60 - 80 characters of dense prose line after line in thick paragraphs; it is not clear how this translates to lines of code.
In my personal experience (and of couse very subjective) it helps me a lit to have lines that fit the monitor, and I can have 2 parallel windows. Using 120 chars is for me just too much. I do think the golden rule of typography is “all rules can be broken if you know what you are doing”. For me is a soft limit. If splitting a line makes the code less readable, I do allow more. But frankly, that is the case of one in maybe 50k LOC
Re: C Style: My favorite C programming practices (2014)
#93Earlier quoted context omitted.
> This 80 character limit stems from a time where terminals could only display comparatively few characters in a line, a limit we haven't had in decades as screen resolutions grew. The 80 char rule has little to do with old monitors. Has to do with ergonomics, and is why any good edited and typeset book will have between 60 and 80 characters per line.
Then let it be 80 characters from any whitespace on the left-hand side? I find it artificially awkward to have to wrap at a hard margin on the right-hand side. Surely you need to accommodate any indenting you're doing?
Take for example man pages, I find the very comfy to read. And they have generous margins on both sides.
About indenting, I try to avoid deep nesting, usually 3 is a maximum, very rare to need more, if the code has to be easy to read.
Re: C Style: My favorite C programming practices (2014)
#94Earlier quoted context omitted.
No rule is absolute. So you may have some line longer. Anyway I’m VERY skeptic that hardcoding URLs is a good idea at all.
> Anyway I’m VERY skeptic that hardcoding URLs is a good idea at all. They are talking about URLs in comments.
Oh. For comments I think would be ok, if it is a comment by itself, and not needed to particularly understand a piece of code, like in a headers. Still links are much more volatile than the codebases I work with. But I understand that may not hold in many many others setups.
Re: C Style: My favorite C programming practices (2014)
#95I feel like I probably agree with about 80% of this. It also seems like this would apply fairly well to C++ as well. One thing that I'll strongly quibble with: "Use double rather than float, unless you have a specific reason otherwise". As a graphics programmer, I've found that single precision will do just fine in the vast majority of cases. I've also found that it's often better to try to make my code work well in…
The one about not using 'switch' and instead using combined logical comparisons is terrible ... quite opinionated, but that is usually the case with these type of style guides.
As the author 10 years later, I agree. A hard-and-fast rule to ban switch, as that rule seems to advocate, is silly and terrible.
Switch has many valid uses. However, I also often see switch used in places where functional decomposition would've been much better (maintainable / testable / extensible). So I think there's still value in advocating for those switch alternatives, such as that rule's text covers. Not that I agree with everything there either. But, useful for discussion!
Re: C Style: My favorite C programming practices (2014)
#96Earlier quoted context omitted.
That was my way of thinking as I was junior programming.
And now...?
After being burn waaay too many times with one of:
1) write only code (for the sake of “speed”
2) optimization of the wrong piece of code
I do think it is much better to prioritize readability; then measure where the code has to be sped up, and then do changes, but try HARD to first find a better algorithm, and if that does not work, and more processor, or equipment is not viable or still does not work, go for less readable code, which is microoptimized
Re: C Style: My favorite C programming practices (2014)
#97Re: C Style: My favorite C programming practices (2014)
#98Earlier quoted context omitted.
And at the very least, "80-characters-per-line is a de-facto standard for viewing code" has been long wrong. As the post even mentions, 100 and 120 columns have been another popular choices and thus we don't really have any de-facto standard about them!
My opinion is that line width depends on identifier naming style. For example Java often prefers long explicitly verbose names for class, fields, methods, variables. Another approach is to use short names as much as possible. `mkdir` instead of `create_directory`, `i` instead of `person_index` and so on. I think that max line length greatly depends on the chosen identifier naming style. So it makes sense to use 100 o…
C is the worst at naming length since everything is in the global namespace unless you're working on a teeny tiny project. So everything gets clunky prefixes to use as pseudo-namespaces or overly descriptive name to avoid conflicts.
Local variables sure, be short and terse. But that's common in most languages.
Re: C Style: My favorite C programming practices (2014)
#99I agree with most, and most of the others I might quibble with, but accept. However, the item to not use unsigned types is vastly stupid! Signed types have far more instances of UB, and in the face of 00UB [1], that is untenable. It is correct that mixing signed and unsigned is really bad; don't do this. Instead, use unsigned types for everything, including signed math. Yes, you can simulate two's complement with uns…
In the vast majority of cases, integer overflow or truncation when casting is a bug, regardless whether it is undefined, implementation-defined or well-defined behavior. Avoiding undefined behavior doesn't buy you anything. If you start to fuzz test with UBSan and -fsanitize=integer, you will realize that the choice of integer types doesn't matter much. Unsigned types have the benefit that overflowing the left end of…
> Avoiding undefined behavior doesn't buy you anything.
This is absolutely false.
Say you want to check if a mathematical operation will overflow. How do you do it with signed types?
Answer: you can't. The compiler will delete any form of check you make because it's UB.
(There might be really clever forms that avoid UB, but I haven't found them.)
The problem with UB isn't UB, it's the compiler. If the compilers didn't take advantage of UB, then you would be right, but they do, so you're wrong.
However, what if you did that same check with unsigned types? The compiler has to allow it.
Even more importantly, you can implement crashes on overflow if you wish, to find those bugs, and I have done so. You can also implement it so the operation returns a bit saying whether it overflowed or not.
You can't do that with signed types.
> If you start to fuzz test with UBSan and -fsanitize=integer, you will realize that the choice of integer types doesn't matter much.
I do this, and this is exactly why I think it matters. Every time they report UB is a chance for the compiler to maliciously destroy your hard work.
Re: C Style: My favorite C programming practices (2014)
#100I agree with most, and most of the others I might quibble with, but accept. However, the item to not use unsigned types is vastly stupid! Signed types have far more instances of UB, and in the face of 00UB [1], that is untenable. It is correct that mixing signed and unsigned is really bad; don't do this. Instead, use unsigned types for everything, including signed math. Yes, you can simulate two's complement with uns…
Author here, 10 years later -- I agree. I'd remove that rule wholesale in an update of this guide. Unsigned integer types can and should be used, especially for memory sizes.
I would still advocate for large signed types over unsigned types for most domain-level measurements. Even if you think you "can't" have a negative balance or distance field, use a signed integer type so that underflows are more correct.
Although validating bounds would be strictly better, in many large contexts you can't tie validation to the representation, such as across most isolation boundaries (IPC, network, ...). For example, you see signed integer types much more often in service APIs and IDLs, and I think that's usually the right call.