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

331–340 of 395 posts

Re: There’s No Such Thing as Clean Code

#331

Post by MattGaiser »

cardinalfang wrote: post #133
MattGaiser wrote: post #11

In my 5th role where I write code, and I have dealt with so many different approaches and definitions of "best practice" that at this point I just roll over to whatever the generally agreed approach is at my current org and mimic it as best as possible. In one organization, I have even had two seniors go back and forth telling me to remove what the other senior told me to put in. The entire process of defining "clean…

That can probably be automated. clang-tidy has some opinionated linting rules that contradict each other, just enabled these and choose to auto-fix.

Oh, if only people agreed on the automation. Those two seniors used different preferred linters as well.

Re: There’s No Such Thing as Clean Code

#332

Post by DerArzt »

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.

How are defining cheep, and how big is the metaphorical house? Developer time is not free (unless you are working a personal project) and if an hour or two up front of planning things out stops you from making a lynch pin mistake that needs to be re-written it is better to do the planning.

If the amount of time that it takes to rewrite something is trivial (a week or less) then you aren't working on something all that big/complicated.

Re: There’s No Such Thing as Clean Code

#333

Post by yakubin »

kgeist wrote: post #326
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"…

>the default case is that you want everything public I'd say that's only true for objects whose purpose is to merely group semi-related data together for copy/transfer/storage, nothing more. If your object has invariants/rules, it's a completely different story. >legitimate uses of "private" exist, but are rare So if you have a domain object with certain invariants (and any serious project has plenty of those), who m…

I've partially responded to that already[1][2]. Let me add to that, that when you group together data, a lot of invariants are preserved by the logic you already wrote for the types you compose your types of. Most basic grouping of objects is a struct. It's a product type. Often what I want really is the product of all the states of the component types, without eliminating any combinations. And in the case of sum types: I practically always want all the states. All the invariants are already handled in the types being summed. Not for transfer/storage, but because it logically makes sense. Another thing is that "make invalid state unrepresentable" is a good guideline, but it can lead you into a corner, where you write a lot of code just to make sure that your type system proves that a certain error is not representable by a type, when this error is trivial, unlikely and would take seconds to debug at runtime (maybe would even be so obvious, as to not need any debugging at all). Just because a certain invariant is true in a domain, doesn't mean that it needs to be encoded in the type system. We need to choose what's the most productive use of our time as developers. Those are trade-offs.

I do not deny the usefulness of ADTs (which is what "private" is all about). I question whether it's the right default. My experience tells me it isn't. Whether you call my style of programming "OOP", is irrelevant to me. This term, after decades of evolution, doesn't mean anything anymore. I certainly don't treat it as a badge of quality and don't consult any definition of it before judging whether a particular technique in programming is useful or not.

[1]: https://news.ycombinator.com/item?id=30112738>

[2]: https://news.ycombinator.com/item?id=30113932>

Re: There’s No Such Thing as Clean Code

#334

Post by D-Coder »

dt3ft wrote: post #92
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…

> Don't comment out code, just remove I hate commented out code, but this doesn't work in every situation. While working on a clinical information system, we had frequent "please bring it back" requests that came a few months after things were removed (also by request). Relying on source control is nice, but unless you document every feature/removal or use very extensive commit messages, finding the code that was rem…

> we had frequent "please bring it back" requests that came a few months after things were removed (also by request)

Not exactly relevant to this discussion, but it sounds like a good case for a config flag. Let them turn it on and off as often as they like.

Re: There’s No Such Thing as Clean Code

#335

Post by bobthechef »

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…

No post body was provided.

Re: There’s No Such Thing as Clean Code

#336

Post by jmchuster »

MauranKilom wrote: post #113
jmchuster wrote: post #111

Code needs to be able to do what you need it to do. So anything that makes that job harder, could be considered not "clean". That might include... - code that is inconsistent. This causes additional overhead and mental burden when thinking about code. Trying to find what's truly logically different is hard when there are additional differences that shouldn't be there in the first place. - incomplete code. This might…

> Code needs to be able to do what you need it to do. So anything that makes that job harder, could be considered not "clean". That reinforces the author's point that "clean" is synonymous for "good", without any added precision. Try interchanging the two in your comment - it reads exactly the same.

Hmm, i don't think they're directly interchangeable. I think of clean as specifically what impacts your ability to write new code. If the code performs horribly, doesn't scale, has lots of security holes, that could still be considered "clean", if you are easily able to implement all the changes you want.

Re: There’s No Such Thing as Clean Code

#337

Post by d0mine »

skohan wrote: post #173
jcbrand wrote: post #168

Earlier quoted context omitted.

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…

Yeah this just hasn't been my experience. If you're working on a house you measure twice and cut once because the cost of reworking physical materials is a lot more expensive than the cost of doing a second measurement. If you could delete half your house and re-build it at zero cost, it might be more valuable to just go for the first attempt and learn from it rather than trying to do everything in theory up front. I…

I don't know about your experience but refactoring is just not on the menu in most commercial environments I'm familiar with, therefore if you always pick the first solution that cones to find, it is likely you have to leave with the consequences of the hack for a long time (until the system crumbles under its own complexity).

Re: There’s No Such Thing as Clean Code

#338

Post by kaba0 »

skohan wrote: post #247
marcos100 wrote: post #222

Earlier quoted context omitted.

I think your incremental design delivers better results because you already know or at least have a hunch of what wouldn't work and avoid that. You have an abstract architecture when starting and change accordingly on the fly, while programming, using your own best practices. Top down and bottom up architecture have their places. Being extreme in favor of one side is usually bad, as almost anything in life.

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 encapsulate, as opposed to the 34th API endpoint. So what it means is that certain domains have much higher essential complexity and at that point the average encapsulation given by OOP/language tools are not sufficient to contain these parts, complexity will triumph and the whole program has to be viewed as one unified whole. Concurrent applications are a similar can of worms.

Re: There’s No Such Thing as Clean Code

#339

Post by hinkley »

skohan wrote: post #330
hinkley wrote: post #327

Earlier quoted context omitted.

If it were loosely coupled it wouldn’t be an anecdote in this conversation. There is no “I”, there is no “you”. There is only “us”. I can only control Us so much, and I don’t have a time machine. People who only have green field projects as their context are very frustrating in conversations like this. They make suggestions like, well, don’t fuck up in the first place. I don’t know what your history is but that’s the…

Not that it matters but I've worked on a mix of green-field projects and mature codebases in various domains with teams of various sizes over more than a decade of professional experience. I could assume you're throwing shade on "prolific programmers" out of some sense of insecurity, but it wouldn't be fair to generalize about strangers on the internet ;)

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 world problems.

Kindly let the grownups talk and keep your flash card answers to yourself.

Re: There’s No Such Thing as Clean Code

#340

Post by robertlagrant »

valenterry wrote: post #40
robertlagrant wrote: post #14

Earlier quoted context omitted.

Fair enough - I haven't done that. I'd be surprised if having loads of anonymous, untested functions would make such a thing more manageable, though.

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.
Post reply on HN