Programming Style Influences | Hacker News Reader

Programming Style Influences

tratt.net

45 pointspanic14 comments

> I used long variable names (on the basis that they helped readers understand what was going on), lots of whitespace (on the basis that it helped readers understand what parts of a file were most related to each other), and wasn't afraid to duplicate code with minor variations (on the basis that each variation was then clearer to read).

I always contend that we should strive for understanding of the whole over making each statement as clear as possible. Local variable names should be short. Variable names that span larger contexts should be as long as necessary to disambiguate it and provide context. I find less senior devs focus on the zoomed in context rather than the larger one. I say that whitespace, especially vertical space usage needs to justify itself. Allow as much context to fit on the screen as long as density doesn't go too far into being unreadable. The standard line length limit convention is a good rule of thumb.

> I now believe the reason is fairly simple: in essence, OpenBSD's style squeezes more code onto the screen.

> Local variable names should be short

It depends on how complex the functions/algorithms are, and what mental references can be assumed.

Local variable names help explain how/what the function does. Function names and context might only be enough to explain the intended output.

Yes it depends on context, but you should be able to lean on the existing context to shorten local names. E.g. a lambda param dealing with a collection of xxx_yyy_zzz_items can just be called item or xyz_item (if there are other item-like things nearby). Only lengthen the method body or take up vertical space with long names if it adds more than it detracts from reading and understanding the whole.

> It makes local chunks of code (e.g. for loops) a bit harder to read but gives the reader a better sense of the wider context (e.g. a function or set of related functions). This, I believe, is a good trade-off because, in programming, the wider the context one is considering, the harder it is to gain a good understanding of that context. My style made understanding local context easier but made it noticeably harder to understand wider contexts.

I wish I could remember in which thread I found a similar comment here within the last week or so.

Painfully-heavily paraphrased, they said that a narrative/shorter function style of programming makes it easier to understand the intent of the logic/individual functions but harder to follow the overall flow, because you tend to have to jump frequently between functions in different parts of the file.

There is an IDE (probably a LISPer) that allows for the inline expansion of functions without having to move the viewport. It's amazing the IntelliJ doesn't have this yet.

That echo command immediately made me wonder why the nflag wasnt initialized to 0, saving 2 lines of code.

Good question! I'm not entirely sure, perhaps it's defense against the compiler optimizing the initialization out?

Ever met someone who despises embedded statements?

  if (condition)
  {
    ...
  }

  if (condition)
    ...

Perhaps they're paid by lines of code.

I don't write C at all and the *++argv thing is obvious to me? Look at the pointer of argv, then look at its sibling?

That's not what the expression does. It means "first increment argv (so it points to the thing at index 1 in the original argv array); then dereference it". (Contrast *argv++, which dereferences at the initial pointer value, and then increments the pointer variable.)

A lot of that sort of pointer pre/post-increment/decrement comes down to "idiomatic ways to write things", which are easier to read when you've seen them a hundred times before. Personally for this specific case I'd have split the increment to its own line -- because conceptually the job that is doing is "skip over the program name in argv[0]", whereas everything else in the if() is the entirely separate "see if the next argument, if any, is '-n'".

According to the code, will the nflag work if you put it at the end? (e.g. 'echo hello world -n')

Nope, and that's by design.

"The BSD echo checks the first argument for the string -n which causes it to suppress the newline that would otherwise follow the final argument in the output."

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/e...

How does *++argv not run accidentally run over the end of the buffer?

Is this some sort of BSD specific behaviour?

I have no idea who my code style influences are.

I don't really think about code that much, any more than most people think of paper plates. I would know a bad one if it's flimsy or dirty, otherwise I don't think of them at all unless they are really exceptional.

There are programmers I respect, and take inspiration from, but mote for their architecture, functionality, or documentation, then their code.

Come to think of it, I have actually only read a few files of code at most from most of my favorite programmers.

RealThunder is one of my favorite programmers in the world. I don't know what he did or how he did it, but he fixed the topological naming issue in FreeCAD, and made it about 5x more practical, and mostly solved one of the key missing things in the whole FOSS ecosystem. He didn't just make a proof of concept or a script you can maybe get to work in an hour, he literally has an AppImage on his GitHub, taking some really algorithms and making true software with them, not just code.

He has his issues, but I respect Poettering for how solid, consistent, and comprehensive his recent software is, and how he wasn't afraid to go beyond "init system" and make a real system management daemon.

I respect Torvalds because... Linux works. It's an OS. It's good at being an OS. And because he is open to new technologies like Rust. I'm not sure I could name anything specific about the kernel that makes it special, besides the fact that it's not buggy and has all the features you need, but that's a good thing. It just needs to be an OS, with lots of community support and drivers.

I respect Van Rossum for the way he curated the feature set of Python, never allowed it to be left behind by changing tech, and really, really, valued practicality.

I respect Wim Taymans for making media sane again. There are essentially no major issues with PipeWire aside from compatibility issues due to it being new.

GStreamer is admittedly at times a nightmare to work with, but that's just because media is hard. For a huge class of problems I wouldn't really think of using anything else.

Fabrice Bellard is wonderful because he does world class things, any one of which would be noteworthy, in multiple domains, usually involving some pretty amazing low-level algorithmic work.

And then there's the stuff that's hard to attribute to any one person as far as I know, but still greatly influences me.

Freedesktop provides an absolutely amazing amount of convenience to the user with very little programmer effort to interact with it.

NetworkManager brings all your network needs together in one place, along with Firewalld that brings all your firewalling together the same way.

Debian is, along with red hat, near synonymous with Linux for me, and they rarely stray from or fail at the mission of providing a rock solid OS where packages don't break.

I wish SyncThing would expand just slightly and offer plugin support, but nonetheless they are the shining example of how self-hosting anything should be.

Linux Mint is unrivalled, as far as I can tell, at being what Windows always should have been.

Reply on news.ycombinator.com