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

“Clean code” isn't actually clean

sdegutis.com

Post reply on HN
Print view View original

31–40 of 54 posts

Re: “Clean code” isn't actually clean

#31

Post by aidenn0 »

RE: Automated testing.

Modulo certain forms of static analysis, your code is ultimately only as good as it is well tested[1]. Non-automated tests do count here, but for long-maintained codebases the cost of automating pays for itself very quickly.

1: Note that pretty much all code has been informally integration tested (A "can I run it" type of smoke-test is a very simple integration test). Similarly all compiled languages (and any interpreted languages that parse an entire file before running code) has some static analysis, as syntax errors will be caught. Unless you check in code without compiling or running it, you are already doing some testing.

Re: “Clean code” isn't actually clean

#32

Post by kristianp »

FrankyHollywood wrote: post #27

Most guru's take an 'all or nothing' approach, this goes beyond programming, look at food-guru's "eat only carbs, never eat refined sugar" etc. This is for me the same as "always do TDD, never use static methods". People without experience often look at guru's because they can not yet think for themselves. I'm a developer in my 40s, have done a lot of projects in a lot of different companies. Having this experience g…

Please, it's just "gurus", no apostrophe needed.

Re: “Clean code” isn't actually clean

#33

Post by hyperpallium »

flohofwoe wrote: post #3

IME the 'best' code solves an existing problem with the least amount of code, is human-readable, and easy to throw away (instead of being 'future proof'). Of course this 'easy to throw away' will also lead to a slow replacement process of 'good code' (that's easy to replace) with new 'bad code' (that's incrementally harder to replace) and eventually each software project will end up in the same broken mess, no matter…

Make it easy to throw away; you will, anyway (to mix-gurus).

The problem with modules that are easy to throw away is that the hole they leave is not so easily discarded. This negative space traces the module boundary; the interfaces between modules.

The only way to throw away interfaces is to throw away...? Everything. You will, anyway.

Re: “Clean code” isn't actually clean

#34

Post by flor1s »

I love the story about a group of American car manufacturer executives visiting factories of Japanese car manufacturers in the 80's. After returning to the US they were asked about their visit and they remarked that the Japanese did not show them their real factories, as the Japanese factories were too clean according to the American executives. As it turns out, a clean work environment (and that includes source code) has benefits if you are doing logical work.

Re: “Clean code” isn't actually clean

#35

Post by chris_wot »

There is something really cool about looking at a large enough codebase, and just reading it. Then when you absorb it, then you might see a way to refactor it. I did this with the error handling code in the VCL module of LibreOffice. Frankly, I just did some renaming and a small bit of logic changes, but it just made the code far easier to understand and work with.

Re: “Clean code” isn't actually clean

#36

Post by flohofwoe »

pul wrote: post #9
flohofwoe wrote: post #3

IME the 'best' code solves an existing problem with the least amount of code, is human-readable, and easy to throw away (instead of being 'future proof'). Of course this 'easy to throw away' will also lead to a slow replacement process of 'good code' (that's easy to replace) with new 'bad code' (that's incrementally harder to replace) and eventually each software project will end up in the same broken mess, no matter…

Replace `least amount of code` with `least amount of complexity` and I completely agree!

Yes that's better. The intent was to not have unnecessary code (often happens when when 'cargo-culting' some design pattern).

Re: “Clean code” isn't actually clean

#38

Post by arkh »

habitue wrote: post #6
atdt wrote: post #5

What's the fence story?

Chesterton's Fence: https://en.wikipedia.org/wiki/Wikipedia%3AChesterton%27s_fen...

That's why you document why you do things some way and not how. So when the why changes or disappear you can change things.

Same problem with rules. Document why they exist.

Simple coding example: the one exit rule. It exists to make easier the resource management in a function. So it is useful in languages for which the coder has to manage resources. For a scripting language or one where resources are managed by the language? No. So there you can enjoy early returns.

Re: “Clean code” isn't actually clean

#40

Post by danielbarla »

pul wrote: post #9
flohofwoe wrote: post #3

IME the 'best' code solves an existing problem with the least amount of code, is human-readable, and easy to throw away (instead of being 'future proof'). Of course this 'easy to throw away' will also lead to a slow replacement process of 'good code' (that's easy to replace) with new 'bad code' (that's incrementally harder to replace) and eventually each software project will end up in the same broken mess, no matter…

Replace `least amount of code` with `least amount of complexity` and I completely agree!

This has been my "go-to" definition for a while, though I'd add a caveat: complexity can be subjective, based on the reader's particular experience or background.
Post reply on HN