Live data from Hacker News

There’s No Such Thing as Clean Code

steveonstuff.com

361–370 of 395 posts

Re: There’s No Such Thing as Clean Code

#361
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…

People who have been coding for a while learn not to repeat their mistakes. Their code contains good-ish abstractions and other “clean code” features because they intuitively know what they are doing. The code they just wrote to get something done & shipped is probably somewhat “clean” by most standards. But communicating those ideas to less experienced developers is where the problem comes in and all the prescriptiv…

Almost right ;)

Novices need simple rules to follow. The world of a novice is filled with uncertainty, they have nearly zero intuition as to what's good or bad, so simple rules that get them 80% there are essential. Otherwise they'd get lost in the complexity.

However, with time, as they gather experience, learn, and mature, they should be able to figure out the reasoning behind the rules they were once given. That then will allow them to make decisions on whether the rule is appropriate for the given context or not.

Of course, getting to that point requires continuous improvement, which is why many, if not most, programmers don't get there.

Example: "Never use `goto` in C." - great advice for a beginner, they'd just make their code into spaghetti. However, a seasoned coder knows that `goto` is only a problem when used to jump to arbitrary points in the code, so using it to reduce duplicated error handling is perfectly fine.

Re: There’s No Such Thing as Clean Code

#362
post #352

Earlier quoted context omitted.

But there's also such a thing as over-planning. If every function you write, you are thinking about 100 different rules about "best practices" you can end up not writing anything at all. Sometimes it's better to accept some level of imperfection first and refine later.

Sure, but your reply to Jcbrand was dismissive of the idea that there is any value to thinking ahead. Jcbrand was not advocating 'thinking about 100 different rules about "best practices"', only that it is useful to try to work out the consequences of the choices you make, in advance of those consequences being revealed to you by failed tests (or failures in use.) I have no idea why there is a large (or at least voca…

I mean it's always a bit of a middle ground isn't it? I'm not suggesting that you should literally just sit down at a keyboard and blindly start typing - of course you want to have at least some concept of how you want to approach the problem.

My point is more that coding itself is an excellent tool for probing for solutions. In many cases I think "software design" is over valued, and time spent prototyping is often more valuable than time spent thinking though the problem if you want to arrive at a high quality answer.

Re: There’s No Such Thing as Clean Code

#363
post #347

Earlier quoted context omitted.

No, It’s an overdeveloped sense of justice. I just punch up at condescending people. Every discipline has a bunch of armchair people who don’t understand the problem who think “get more exercise” is the response to depressed people or people with chronic fatigue, “eat fewer calories” is the answer to weight issues or diabetes, or “write it right the first time” is a useful response to people trying to solve real worl…

> Kindly let the grownups talk Well one of us is certainly being condescending ;) And did you really answer twice to the same comment? My goodness I must have really struck a nerve.

Well this escalated quickly

Re: There’s No Such Thing as Clean Code

#364
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…

Bob himself has mentioned that many of the rules are contradictory to one another. I can't remember what examples he gave. I think it was in his video series.

Re: There’s No Such Thing as Clean Code

#365
post #200

Earlier quoted context omitted.

Probably not literally without cost, but if the code was written with disposability in mind combined with just a little bit of pre-planning, then rewriting or refactoring should be indeed trivial.

When start off with "wrong" higher level design concepts, neither of those is trivial. If you're writing a function implementation without thinking about design, well you might be right.

When starting, yes it's easy to replace code, even with a shitty design. If it had to take more than ten hundred thousands lines of code to realize that the design is wrong, then it means the author lacks enough awareness or foresight to plan ahead, and no amount of planning will fix that. Code should be replaced/rewritten if the earliest signs faulty design show up, which should be trivial if the code was and remains "disposable".

Re: There’s No Such Thing as Clean Code

#366
post #338
post #247

Earlier quoted context omitted.

I'm just having trouble understanding what you're talking about. Like what would be a concrete example of how a poor up-front design decision would paint you into an unrecoverable corner?

My experience says that you might not need much design for a typical CRUD app, but try to write a JVM/compiler/database and you will quickly see that a bad design pretty much aborts the given project and you have to start from almost scratch. There is no incrementel rewrite between different stack/heap handling as those are an absolutely central parts of the design, which are pretty much impossible to try to encapsul…

All the technologies you mentioned do undergo large component rewrites and refactoring very often. It's true that e.g. the JVM is sometimes hemmed in by decisions from the past. But it is a decades old project and it is not clear that more up front design and deliberation would have future proofed the project for the language and VM conventions of the 2020s.

I have applied incremental design to concurrent applications and a compiler + stack VM project that runs in embedded environments. You don't go in blind. You do need domain experience and broad strokes knowledge of the conventions. You make some major architectural decisions up front but these don't involve much planning or design. Contrary to your point about CRUD apps, API design is harder to achieve incrementally since it is an interface and requires cross-team (sometimes cross-organizational) iteration. It's still possible, but your organization needs to be equipped for incremental/agile work.

Re: There’s No Such Thing as Clean Code

#367
post #353

Earlier quoted context omitted.

I think the “somehow” is not too hard to guess… it is easy to think that “class” is the only way to declare a class, especially since “struct” is taken from C. I’m sure very few intro C++ explanations ever mention “struct” as a way to declare a class.

There's quite a lot about C++ which wouldn't be covered in a simple tutorial, but the meaning of class/struct is a pretty basic part of the language, hardly obscure. Maybe it's something you could miss if you're coming from a strong C background and still thinking of C++ as C-with-classes, but otherwise it's something any serious user of the language would pick up.

This comment represents some of the worst elitism I see in the programming community.

Re: There’s No Such Thing as Clean Code

#368

Earlier quoted context omitted.

Do you test every line of code you write separately? Probably not. You test a function that has 5 lines of code. Same for anonymous functions. You test the functions that use them and that's usually enough. If not, then that is a good indicator of separating them out into named functions.

This is the wrong way to think about it, though. A function encapsulates some behaviour, regardless of how short or long it is. You don't test each line (directly); you test each function's mode of operation. So a function with one if statement in it potentially needs two (happy path) tests.

I don't think we disagree. It's just that a lambda doesn't change this. If the lambda itself also contains a branch, then yeah, you should probably test the outer function with at least 2 inputs.

Re: There’s No Such Thing as Clean Code

#369

Earlier quoted context omitted.

This is the wrong way to think about it, though. A function encapsulates some behaviour, regardless of how short or long it is. You don't test each line (directly); you test each function's mode of operation. So a function with one if statement in it potentially needs two (happy path) tests.

I don't think we disagree. It's just that a lambda doesn't change this. If the lambda itself also contains a branch, then yeah, you should probably test the outer function with at least 2 inputs.

I agree, except I think that a lamdba is an arbitrary line to draw for that as well. Why not stop at the main function and give it a load of inputs? A five line lamdba looks a lot like a named function, just harder to test, reuse, and debug in a stack trace.

Re: There’s No Such Thing as Clean Code

#370
post #27
post #5

Coding is a highly subjective and creative endeavor. "Clean code" is akin to "well written" for writers. Sure, you can analyze and even be able to define some good practices, but because we are always creating something new that has never done before, and the field is infinitely complex, no rules can be set in stone and applied across everything. In my opinion there's nothing wrong with calling code clean, we don't h…

Writing is a great metaphor: there aren't any hard-and-fast rules and there's certainly a subjective quality to it... but also, some writing is clearly better and some writing is clearly worse. Maybe there is no such thing as "good" writing because writing can be "good" in different ways or because we can never fully define what "good" means, but that doesn't mean that all writing is equal or that "everything is a tr…

> Writing is a great metaphor: there aren't any hard-and-fast rules and there's certainly a subjective quality to it... but also, some writing is clearly better and some writing is clearly worse. Maybe there is no such thing as "good" writing because writing can be "good" in different ways or because we can never fully define what "good" means

There are different writing styles (and so guide styles associated) for different objectives. Eg, journalism, with a pyramid model designed and refined to ease the process of assimilating information which is different from the playscript style model designed to give general instructions on how to flesh out and enact events.

Both these styles (I intentionally chose for their more obvious rules and usage) have different hard-and-fast rules and applying one instead of the other wouldn't work.

Now, there will be a subjective quality but there are also objective qualities to writings produced with these styles (structure, count of words, choice of wording for description, timeline of events reported, etc.).

Now, of course regarding novels, storytelling, the newyorker, writings that are intended to be read, alone, to tell a story, to convey more than facts and the most objective description of reality yada yada.

And then there are technical manuals. I think code is a technical manual for two kind of audiences: humans and computers, so compromises are made and rules for clarity and brevity can be layout.

Post reply on HN