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

There’s No Such Thing as Clean Code

steveonstuff.com

Post reply on HN
Print view View original

211–220 of 395 posts

Re: There’s No Such Thing as Clean Code

#211

Post by zozbot234 »

serial_dev wrote: post #142
dtech wrote: post #110

Earlier quoted context omitted.

Seems garbage advice to me. Now you've polluted your production code, likely forever. I don't see a situation where using an issue tracker + good commits - e.g. 1 commit for the 1 PR linked to the ticket that removes the feature - won't result in a superior situation from a maintenance and traceability perspective.

Yes, I agree with you. Another thing is how do you know which of the removed features will be asked to be put back? You can't really know. You can guess, but that will leave you with many classes/functions commented out only in the hope that one day one of them will be requested to be put back. This leads to nobody daring to remove old code for months/years. Then, one day, a new coder on the team just ask WTF is this…

I thought the best practice for "keeping stuff around just in case" was an attic/ directory in the source repo. That way you're still benefiting from version control, but it's also clear that the code is totally untested and might bitrot at any time.

Re: There’s No Such Thing as Clean Code

#212

Post by barrkel »

yakubin wrote: post #96
onion2k wrote: post #59

The Uncle Bob Martin definition of "clean code" from his book "Clean Code: A Handbook of Agile Software Craftsmanship" is a set of rules that absolutely are not at odds with one another. If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. There's a decent summary here - https://gist.github.com/wojteklu/73c6914cc446146b…

> If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. I found that a lot of those guidelines lead to the exact opposite. Examples: - Prefer polymorphism to if/else or switch/case (oh, the joy of tracing a simple task through 50 files) - Use dependency injection (same as above) - Hide internal structure (that "private"…

Private - or visibility scoping generally - is absolutely essential when you program in an environment with multiple teams.

In its absence other people take dependencies on internal details which makes code much harder to refactor later. Lack of scoping on visibility increases the surface area of your APIs and increases the likelihood of bugs. Lack of scoping of visibility on state means losing almost all control over preservation of invariants.

Re: There’s No Such Thing as Clean Code

#213

Post by gefhfffh »

skohan wrote: post #203
gefhfffh wrote: post #188

Earlier quoted context omitted.

When can you rebuild at zero cost? I have made similar avoidable mistakes of not thinking it through enough, could have saved me a lot of rewriting, which was pretty expensive

Rewriting is incredibly cheap! And you learn a lot from the failed attempts. Again to the house analogy, if you could just build 3 vestibules to see how they fit with just a little typing, that would be far and away preferable to committing to everything on paper before hand.

No, it is not cheap, generally.

Example:

Dendrite[0] was going to be a Rewrite of Synapse (which was a prototype which ended up going into production). The rewrite started more than 5 years ago, had lots of development breaks and it still is nowhere complete or close to replace a existing Synapse instance (which even today is ... Well ... suboptimal software).

The current plans are to support and use both servers long term, because Synapse is already too widespread.

I wouldn't call that cheap.

[0]: https://github.com/matrix-org/dendrite

Re: There’s No Such Thing as Clean Code

#214

Post by barrkel »

karatinversion wrote: post #116
yakubin wrote: post #96

Earlier quoted context omitted.

> If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. I found that a lot of those guidelines lead to the exact opposite. Examples: - Prefer polymorphism to if/else or switch/case (oh, the joy of tracing a simple task through 50 files) - Use dependency injection (same as above) - Hide internal structure (that "private"…

> Hide internal structure (that "private" is the default in C++, Java and Rust just adds to boilerplate; the default case is that you want everything public (unless you like writing trivial getters and setters just for the fun of it); legitimate uses of "private" exist, but are rare) This is such a strange POV to me. There are cases where your classes are just data records, but any object with logic surely wants to r…

It's nuts. It's deeply naive and utterly unworkable.

Re: There’s No Such Thing as Clean Code

#215

Post by mpartel »

skohan wrote: post #210
mpartel wrote: post #207

Earlier quoted context omitted.

This is true for early high-level decisions. For every-day coding of smallish components in a large project, it matters much less. The more code your design decision will affect, the more up-front planning it deserves.

I would argue if “high level design decisions” are getting in the way of coding, this is a sign of over-design or premature abstraction. If you write sufficiently loosely-coupled code, it’s not hard to re-organize later.

Some examples of high-level decisions: - which web framework? - which database? which ORM? which transaction isolation level by default? - will this game/UI be multiplayer? - what's our testing discipline?

You can't loosely couple around questions like these most of the time, at last not without excessive abstraction.

For "how do I structure this reasonably isolated 0-1kLOC component", I agree, easy to fix later if needed.

Re: There’s No Such Thing as Clean Code

#216

Post by usrbinbash »

RangerScience wrote: post #56
usrbinbash wrote: post #45

The fact that everyone can come up with his own definition of what "clean" is supposed to mean regarding code, tells us something very important about it: It has no intrinsic, defined meaning in the context of code. Saying code is "clean" is like saying food is "tasty"...its a personal opinion, not a defined term.

Strong disagree. It's defined meaning in the context of code is a subjective experience of the coder of "clean", which carries elements of "satisfying", among other things. Maybe: It has no intrinsic, defined meaning in the context of the computing machine.

> is a subjective experience of the coder of "clean"

My subjective experience of grapefruits is that they are yucky. That tells others that I don't like grapefruits, but it tells them nothing about the grapefruit.

It tells them nothing about, what exactly in the interplay between the chemical composition of grapefruit juice, the genetic programming behind my tastebuds, and the personal experiences which shaped my individual perception of "tastyness vs. yuckyness", makes them "yucky" for me.

Re: There’s No Such Thing as Clean Code

#217

Post by bryanrasmussen »

RangerScience wrote: post #44
theonething wrote: post #39

Earlier quoted context omitted.

In my work history, I've never come across code like this, especially "effortless to follow". All the codebases I've worked with have been head scratch causing balls of mud. Am I unlucky or is what you are describing the rare exception?

Both. Head-scratching balls of mud is, IMO, below average; but that lofty height of code described is an extreme rarity. 100% recommend having your own hobby project so you can reach it.

>but that lofty height of code described is an extreme rarity.

I would say lofty height only possible in following conditions:

A model of reality / problem domain that the company has created themselves that does not have to integrate with any other company, or have to follow any laws or regulations.

For example let us suppose you create a company for users to send messages to each other using your app. You can totally control everything in your environment - just your app, your definition of users, you definition of messages. But once you need to connect your app to other apps doing similar things but differently than your model you are going to hit edge cases, and if you have to think about making your app work on multiple environments and there are problems as there generally are you will start to be less lofty, and then after you have been going a while you try to enter a market with regulations, or regulation is handed down affecting your app.

Things are getting less lofty quickly at that point.

on edit: grammar

Re: There’s No Such Thing as Clean Code

#218

Post by CipherThrowaway »

jcbrand wrote: post #168
skohan wrote: post #153

Earlier quoted context omitted.

The more code I've written, the less I care about code quality. I think the things I could point to in my coding practice which would make the code I write now better than the code I wrote 10 years ago would be: - I minimize interdependencies (changing a line of code should not affect something un-related) - I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction/des…

Back in university I had an experience that was really instructive. For a project we had to write a program that differentiates mathematical equations. I dove in and just started writing code. Eventually, I realized that I had made a design error and that my code was much more complicated and cumbersome than it needed to be and I was getting stuck due to the complexity of the monstrosity I created. Unfortunately I fi…

I think this is the kind of thing you learn at uni and then potentially unlearn later on. Over the years I became better at using code to explore problem spaces and as a design tool. Nowadays I feel that incremental design delivers better results in less time than upfront design.

Re: There’s No Such Thing as Clean Code

#219

Post by absurddoctor »

ahmaman wrote: post #165
rawoke083600 wrote: post #135

So True ! After 25+ years of coding, I know one thing. I STILL don't know how to "code correctly". And apart from a few gifted individuals (Rob Pike, Fabrice Bellard Bobby Bingham [ffMpeg team] etc) I'm HIGHLY suspicious of ppl and programmers who claim "they can program correctly" and that "this xyz is the correct way/stack/method/arch". Background:CS grad, start coding at around 13 (thank you dad !) I am well verse…

> It would be cool if code-reviews were done "anonymously" Sometimes during code-reviews I find myself wanting to leave 100+ comments. Instead I settle for the few major ones and leave behind most of the minor stuff. I don't want to be perceived as someone who is difficult to work with, so try to pick my battles wisely. Wonder if anonymous code-review that helps with that.

I’ve no experience with anonymous reviews, but have had experience with two approaches that help with the minor comments. One is an agreed upon method of identifying potentially minor comments. We call them ‘nits’, with the understanding that they can be dismissed by the code submitter without any changes. The second is the opposite of anonymous reviews where we meet up and have a ‘live’ review. This makes going over any such bits pretty quick and painless, as it avoids the back and forth that text comments sometimes result in. It has the added benefit of being able to discuss the ‘why’ of things more easily, which is especially useful if the reviewer is less familiar with the code involved.

Re: There’s No Such Thing as Clean Code

#220

Post by ChrisMarshallNY »

> If you’re hacking away on your own then you can do what you want

I have a different point of view. I am the person that most often maintains the code that I write. It’s really important that I be able to understand it. Not just at a “tactical” level (This function does this), but at a strategic level (The architecture is designed as a functional abstraction of the model).

My code tends to be quite well-structured, highly documented, and a bitch to understand. I will often employ fairly byzantine architectures, pursuant to testability, usability, and localizability.

Works well, though, and ages nicely. I’ve written APIs that have lasted for 25 years.

Post reply on HN