Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Style: My favorite C programming practices (2014)

github.com

Post reply on HN
Print view View original

41–50 of 139 posts

Re: C Style: My favorite C programming practices (2014)

#41

Post by beachy »

f1shy wrote: post #22
kleiba wrote: post #12

Earlier quoted context omitted.

Agree. 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. Another argument for shorters lines is that it is much harder for us to read any text when lines get too long. There's a reason why we read and write documents in portrait mode, not landscape. But in sum, I don't think there's a need…

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

80 column punched cards were a very strong influence

Re: C Style: My favorite C programming practices (2014)

#42

Post by xipix »

LeoNatan25 wrote: post #24

> 80-characters-per-line is a de-facto standard for viewing code. Readers of your code who rely on that standard, and have their terminal or editor sized to 80 characters wide, can fit more on the screen by placing windows side-by-side. This is one of the silliest practices to still be enforced or even considered in 2024. “Readers” should get a modern IDE/text editor and/or modern hardware.

A proportional font really helps ergonomics too.

Re: C Style: My favorite C programming practices (2014)

#43

Post by rramadass »

lifthrasiir wrote: post #28

While I don't agree every single point (see below), one thing great about this document is that the author tried to really elaborate one's opinion. That makes a good point to start the discussion regardless of my own opinion. Thus I'll contribute back by giving my own judgement for every single item here: Absolute agreement * Always develop and compile with all warnings (and more) on * #include the definition of ever…

Nice Summary of the Article ! Thank You.

Re: C Style: My favorite C programming practices (2014)

#44

Post by wruza »

f1shy wrote: post #22
kleiba wrote: post #12

Earlier quoted context omitted.

Agree. 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. Another argument for shorters lines is that it is much harder for us to read any text when lines get too long. There's a reason why we read and write documents in portrait mode, not landscape. But in sum, I don't think there's a need…

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

As a part of ergonomics auditory, I really prefer 100-115 column soft limit for code editors, log viewing and console, because that’s how my single display dev setup works best. Otoh if I’m using IDEs with big sidebars like {X,VS}Code, then I need two displays and/or a full-width IDE anyway.

While I understand that this is an anecdotal preference, to me it doesn’t feel like the 80 column standard fits any modern dev workspace perfectly, tbh. (By modern I don’t mean “shiny”, just what we have now in hw/sw.)

Re: C Style: My favorite C programming practices (2014)

#45

Post by wruza »

vbezhenar wrote: post #29
lifthrasiir wrote: post #14

Earlier 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…

Also on age, e.g. I began to prefer grandma font size from time to time for better focus, and that changes my workspace geometry.

For mkdir all-in, meh. It’s okay for mkdirp or rimraf, cause these basically became new words. But once you add more libs or code to a project it becomes a cryptic mess of six-letter nonsense. English code reads best, Java just overdoes it by adding patterns into the mix.

Re: C Style: My favorite C programming practices (2014)

#46

Post by mark_undoio »

vbezhenar wrote: post #32
robxorb wrote: post #5

> Write correct, readable, simple and maintainable software, and tune it when you're done, with benchmarks to identify the choke points If speed is a primary concern, you can't tack it on at the end, it needs to be built in architecturally. Benchmarks applied after meeting goals of read/maintainability are only benchmarking the limits of that approach and focus. They can't capture the results of trying and benchmarki…

I don't know if this embedded development still alive. I'm writing firmware for nRF BLE chip which is supposed to run from battery and their SDK uses operating system. Absolutely monstrous chips with enormous RAM and Flash. Makes zero sense to optimize for anything, as long as device sleeps well.

A little over 10 years ago I was doing some very resource-constrained embedded programming. We had been using custom chip with an 8051-compatible instruction set (plus some special purpose analogue circuitry) with a few hundred bytes of RAM. For a new project we used an ARM Cortex M0, plus some external circuitry for analogue parts.

The difference was ridiculous - we were actually porting a prototype algorithm from a powerful TI device with hardware floating point. It turned out viable to simply compile the same algorithm with software emulation of floating point - the Cortex M0 could keep up.

Having said all that though: the 8051 solution was so much physically smaller that the ARM just wouldn't have been viable in some products (this was more significant because having the analogue circuitry on-chip limited how small the feature size for the digital part of the silicon could be).

Obviously that was quite a while ago! But even at the time, I was amazed how much difference the simpler chip made actually made to the size of the solution. The ARM would have been a total deal breaker for that first project, it would just have been too big. I could certainly believe people are still programming for applications like that where a modern CPU doesn't get a look in.

Re: C Style: My favorite C programming practices (2014)

#47

Post by wruza »

f1shy wrote: post #21
wruza wrote: post #8

Treat 79 characters as a hard limit Try pasting a long URL into a comment describing a method/problem/solution and you’ll see immediately that it doesn’t fit 77 chars and you cannot wrap it. Then due to your hard limit you’ll invent something like “// see explained.txt:123 for explanation” or maybe “ https://shrt.url/f0ob4r” it. There’s nothing wrong with breaking limits if you do that reasonably, cause most limits h…

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.

Only hardcore cool URLs!

Re: C Style: My favorite C programming practices (2014)

#49

Post by wruza »

Keyframe wrote: post #30
LeoNatan25 wrote: post #24

> 80-characters-per-line is a de-facto standard for viewing code. Readers of your code who rely on that standard, and have their terminal or editor sized to 80 characters wide, can fit more on the screen by placing windows side-by-side. This is one of the silliest practices to still be enforced or even considered in 2024. “Readers” should get a modern IDE/text editor and/or modern hardware.

au contraire! considering programming involves a lot of reading, it overlaps (or even comes from) with. best practices from ye olde tradition of typesetting https://en.m.wikipedia.org/wiki/Line_length#:~:text=Traditio... . Aside books and print magazines and newspapers, we still respect that on web sites when reading is involved, why should programming be exempt of ergonomy?

programming involves a lot of reading

Is that true for an average developer, really? Yes, we read lots of manuals, snippets, stackoverflows. But code? One does mostly write code.

And when we do read code, it may lack good naming, structure, comments, clarity, may be unnecessarily complex or hacky. Where does it wrap is the thing one would care about only in perfect code, if at all. Most editors can smart-wrap and clearly indicate it anyway.

Re: C Style: My favorite C programming practices (2014)

#50

Post by eschneider »

robxorb wrote: post #5

> Write correct, readable, simple and maintainable software, and tune it when you're done, with benchmarks to identify the choke points If speed is a primary concern, you can't tack it on at the end, it needs to be built in architecturally. Benchmarks applied after meeting goals of read/maintainability are only benchmarking the limits of that approach and focus. They can't capture the results of trying and benchmarki…

Well, yes. Architect for performance, try not to do anything "dumb", but save micro-optimizations for after performance measurement.
Post reply on HN