Hacker News Reader

Comment by thrower123 | Hacker News Reader

Most of these books that were standards in the 2000s don't hold up great now, just because most of the important parts have diffused and become ambient omnipresent practices.

Putting so much emphasis on variable naming, to take one common theme from Code Complete, Pragmatic Programmer, Clean Code, et al, makes a lot more sense coming out as a reaction against some of the worst excesses of Hungarian notation.

They just aren't the kind of revelation that they were 20 years ago, in part because they've been so successful at molding multiple generations of programmers now.

View on HN

> Putting so much emphasis on variable naming, to take one common theme from Code Complete, Pragmatic Programmer, Clean Code, et al, makes a lot more sense coming out as a reaction against some of the worst excesses of Hungarian notation.

I don't know about that. I just finished cleaning up a codebase where my predecessor named literally any response from any API call "tempJson", regardless of how many hundreds of subsequent lines ended up using it. Some of these "tempJson" variables would get passed to other functions with the parameter also being named "tempJson" or "json". It was nightmarish. I wish this programmer had read and applied the principles in The Pragmatic Programmer, but he hadn't.

I suspect it's not that the context has changed such that the book is unnecessary, it's that most of us have forgotten that many of these principles aren't obvious to newcomers.

Having been there I think it is other stuff, rather the cargo cult bubble selling conferences and consulting gigs is now gone and we got back to the good old days in most companies.

The exception being startups that are still in the phase of attracting dreamers that are going to change the world.

I agree they're omnipresent practices, but still good reading for new-ish devs. Probably about half of my comments on young FAANG peers PRs are "greatest hits" from Code Complete and Clean Code like variable naming, etc.

Regarding variable names I think the correct answer is somewhere in the middle. There's such a thing as too short a variable name, and these days I see it more frequently than I see too verbose a variable name.

I believe the best answer is dependent on context.

How short is too short? How large is too large?

On a shallow for-loop, i and j as variable names is perfectly acceptable and probably desirable - it conveys their meaning in a very concise and familiar manner.

On the other hand, if you're writing a function that's a little outside of your codebase's core areas it might make sense to name things a bit more verbosely and perhaps (the horror) add comments explaining in more detail what those data containers are supposed to hold.

I would love to see the next generation of opinionated formatting tools perhaps use AI models to automatically set and enforce variable naming. Maybe even just some simple heuristics like iteration count variables are 3 characters or less, state values are nouns, etc. would be good enough. Please just completely automate and remove any and all bikeshedding around naming, much like we've done with formatting--it would probably remove 25% or more of all commentary on code reviews.

Design Patterns - I think there are a few obvious ones like Singleton and Bridge, a few non-trivial like Strategy and the rest are just historic artifacts for interviews

Those are comments on the implementation patterns in the Gang of Four book, which are indeed historically situated in the period of the book’s publication and relate to common solutions to problems then encountered. And indeed many of the non-trivial ones are interchangeable: what is State but a Strategy for handling time? What is Abstract Factory but a Strategy for creating objects?

Underlying this is the idea of a Patterns Language for programming: the idea that specific problems can be categorised into general problem shapes, that a satisfactory solution that fits the shape can be named, and that communication is aided by discussion involving those names. The idea of the patterns language is still very much relevant today. Whenever a developer says “this can be a redux saga” or “we’ll use serverless for that”, they are naming a general solution that they believe fits the shape of their specific problem.

I find the names of the patterns unintuitive, more like a language barrier to adoption. Same feeling I got from AngularJS when it was initially published.

All names are unintuitive. The point of Design Patterns is to have a catalog of solutions with names (aka jargon) so we can have higher-level discussions. This requires those involved in the discussion to have a clear understanding of the pattern, which isn't always the case.

Reply on news.ycombinator.com