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

351–360 of 395 posts

Re: There’s No Such Thing as Clean Code

#351

Post by agumonkey »

skohan wrote: post #318
agumonkey wrote: post #254

Earlier quoted context omitted.

very important lesson, more than that actually there's a lot of artistry, poetry, idealism in programming, but as a daily money making activity it just doesn't cut it. You have to reach goals as easily as possible (dry,yagni) fast without painting yourself in corners as much as you can (low coupling, min interdependencies). Finding the right variability points. it's something school don't do well (saying this humbly)…

Yeah I think that there's a bias for programmers to think about artistry, poetry, and idealism in the form of code since that's what we're dealing with all day. But in reality it matters a lot less than we would like to think.

IMO whenever survival (and money, contractual relationships) occur, we will or must go to a different kind of idealism which maximizing the value/effort ratio.

I only "lead" one project (a minuscule thing by all means) and it was the first time I was responsible, and instead of burning out in rabbitholes, I discovered the bliss of being sharp cause I had near no time to allocate to anything. Suddenly only the minimum amount of change was important and you stop caring for so many parameters. It leads to a saner sense of skills and progress.

You also start to understand systemic ideas better, every patch or change will have your brain think "is this gonna rot fast ? or will it be nicely decoupled from the rest and more pros than cons in the future?". No effort is wasted, every step improves the system. It feels very good, and makes you want to do more of that. Unlike 99% of side projects where you spend days on DESIGN.md or TODO or watching conferences about

Re: There’s No Such Thing as Clean Code

#352

Post by skohan »

mannykannot wrote: post #349
geodel wrote: post #345

Earlier quoted context omitted.

Yeah, but >99% code is about using relational DBs and concurrency primitives not developing them. There are somethings that would depend on solid theoretical understanding but most of the software today is much more amenable to trying out things first and reworking failed parts.

In practice, one does not write a single line of code without feeling that it is somehow getting you closer to the desired outcome. If you have the ability to anticipate that it will not contribute to that goal, or that it will create problems on the way, or that there is a better way, even before you have written and tested it, then it would be counterproductive not to do so.

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.

Re: There’s No Such Thing as Clean Code

#353

Post by TillE »

klodolph wrote: post #198
andi999 wrote: post #179

Earlier quoted context omitted.

In c++ a class declared with the keyword 'class' is private by default, and a class declared with the keyword 'struct' is public by default. So if you want public by default just write 'struct' (somehow this is not commonly known). https://en.wikipedia.org/wiki/C%2B%2B_classes

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.

Re: There’s No Such Thing as Clean Code

#354

Post by robertlagrant »

feoren wrote: post #41
robertlagrant wrote: post #3

Earlier quoted context omitted.

20 short functions definitely sound as though they should be explicit. Named, documented, testable. 1 or 2 you could get away with being implicit. 20 requires a lot of understanding as to what's going on!

So here's some TypeScript code I just made up, with a lot of lambdas. It's somewhat typical of code I write all the time. books .join(authors, book => book.author, author => author.id) .filter(([book, author]) => author.lastName === searchText) .map((book, author) => `The Book ${book.title}, by ${author.fullName()}, has ${book.chapters.count()} chapters, totaling ${book.chapters.sum(chapter => chapter.pages.count())}…

I appreciate the large amount of effort you went to to get your point across; that helps with actual discussion, which is awesome.

The context I was talking in mentioned Python not having lambdas. It does have lamdbas (there's even a keyword) so I assumed it meant larger, multi-line lambdas. The code you wrote (glueing together a few mini-lambdas) I would not expect to test independently. I'd feel bad that you can't use SQLAlchemy's even nicer syntax, but I certainly wouldn't expect a test for each of those little things.

Re: There’s No Such Thing as Clean Code

#355

Post by jerome-jh »

antris wrote: 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…

Subjective terms like "clean", "ugly" really hurt our field. OTOH the following attributes are objective and verifiable:

- the code complies with coding conventions in force

- it is correct

- it is not inefficient

I would really love coworkers stick to these three criteria during reviews.

Re: There’s No Such Thing as Clean Code

#356

Post by mannykannot »

skohan wrote: post #352
mannykannot wrote: post #349

Earlier quoted context omitted.

In practice, one does not write a single line of code without feeling that it is somehow getting you closer to the desired outcome. If you have the ability to anticipate that it will not contribute to that goal, or that it will create problems on the way, or that there is a better way, even before you have written and tested it, then it would be counterproductive not to do so.

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 vocal) community of developers whose dogma seems to be that thinking things through is a waste of time (though maybe it is just an overreaction to the equally dogmatic clean coders and similar prescriptivists.)

Re: There’s No Such Thing as Clean Code

#357

Post by RangerScience »

parminya wrote: post #87
RangerScience wrote: post #42

> There’s no such thing as clean code. > ‘Clean’ isn’t a measure of anything useful. Code can’t be clean simply because ‘clean’ doesn’t describe anything about code. Ehhhh. There is absolutely such a thing as clean code. But yes; what there isn't a way to measure code cleanliness (although there's lots of surrogate measures; see every linter) which means there's also no way to render it into a dogma... ...and to (per…

> No. That's the trap of Goodhart's Law. You need something outside of your metrics so that your metrics don't become your target. How can you make a metric out of "we aren't really sure what the direction of change for this feature is going to be, so it should be easy to refactor"? and why would that metric be any more likely to fall victim to Goodhart's Law than "the code should be clean"?

"Easy to refactor", AFAIK, can be approximated via LoC within functions and classes; dimensionality of functions; cyclomatic complexity; etc. Those are the metrics; you can produce reasonable and grounded numerical measurements of them.

But, if you were to just optimize for those metrics, I bet you'd run into issues, whereas if you use those metrics as part of your process for determining if it's easy to refactor, then yeah, I'd expect you to be less vulnerable to Goodhart's Law.

"Easy to refactor" is a goal, not a metric; low cyclomatic complexity is a metric, not a goal. IMO.

Re: There’s No Such Thing as Clean Code

#358

Post by andrekandre »

jwdunne wrote: post #140
bryanrasmussen wrote: post #101

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. In Java (or Java like languages [C#]), which is the language they were really written for. There are many languages for which the precepts of Clean Code are not that great a fit. Also - It's probably time to stop recommending Clean Code - https://qntm.org/clean

Was just about to comment with this link. A useful counterpoint whenever Clean Code comes up. I do think this article makes a lot of valid criticisms and it’s well worth a read. I remember being influenced by it early on but then re-read it as I gained more experience. This article sums up what I felt on rereading.

maybe its time for someone to write "clean code: the good parts"

Re: There’s No Such Thing as Clean Code

#359

Post by stjohnswarts »

skohan wrote: post #153
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…

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…

This is why I'm like "it works, and has worked for months(years) leave it alone and do better next time" to all the young engineers who like to sling around terms like bit rot (bits do not rot) and "technical debt". Technical debt is when the code becomes hard to comprehend or update, not just because of age or you know a new fancy dancy language or DSL of their own design we should be using. Also get off my lawn lol

Re: There’s No Such Thing as Clean Code

#360

Post by anamax »

skohan wrote: post #153
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…

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…

> Besides that, I'm a huge fan of disposable code. In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the problem

My approach is slightly different.

I think for a while and then start on the path that gets me to what I think is a common case. If the whole seems more complicated than reasonable, I back out the part that seems to be troublesome.

Eventually, I get one case "working". That case might not be complete, but it does something.

I then work on an adjacent case, using the same "back out the troublesome" process, going into a bit more detail (or perhaps deciding that some detail on the first case was wrong).

I repeat "work on adjacent cases" until most/all cases are handled. As I do more cases, I use opportunities to reduce the cognitive footprint.

Post reply on HN