Hacker News Reader

Comment by hennell | Hacker News Reader

I think he's really underplaying the main selling point of clean code - the objective of writing clear maintainable, extendable code. His code was faster, but sometimes how it compares for adding new features or fixing bugs by people new to a code base is where you want to optimize.

Should performance be talked about more? Yes. Does this show valuable performance benifits? Also yes. Is performance where you want to start your focus? In my experience, often no.

I've made things faster by simplifying them down once I've found a solution. I've also made things slower in order to make them more extendable. If you treat clean code like a bible of unbreakable laws you're causing problems, if you treat performance as the be-all-end-all you're also causing problems, just in a different way.

It's given me something to think about, but I wish it was a more fair handed comparison showing the trade offs of each approach.

View on HN

If someone is new to the codebase, would you rather they need to open a dozen files to see all of the different virtual functions that could occur at one call site, or open one file?

As tradeoffs go, I don't see opening a dozen files as a big hurdle. I'd take smaller single purpose files over one big file anyday.

Plus how often do you need to see all functions? If there's a problem in RectangleArea function, you go to that file, no need to look in CircleArea. If you're adding 'StarShapeArea' you only care that it matches the callers expectations, not worrying about the other function logic.

Honestly this itself is a massive oversimplification, and a bit of a strawman, and kinda indicates that you still aren’t seeing the nuance.

Yes, if something is understandable in a single file, that’s fine. But also appreciate that too many pieces in the same file can also be confusing and disorienting for people. You also have to consider all the cases in which someone would be opening that file.

You’re basically posing a situation which by its very description is an exception. If anyone is slavishly following these rules, they’re undoubtedly doing it wrong.

Knowing when to apply the patterns is the hard bit. And, in my experience working on codebases worthy of considering these things in the first place, there’s much more to consider than what you’re posing.

I see your point, but no one uses Windows notepad for coding anymore.

There are far worse crimes than having code structure that spans several files.

> There are far worse crimes than having code structure that spans several files.

Sure, but what's the advantage of having your code split over several files? Yes, you can jump between them with an IDE, but that's still a disruption, and it makes it harder to see common patterns that can help you simplify the code.

As demonstrated in the video, splitting up the switch into multiple classes only hurts readability.

You are only seeing a screenful of code at any time, no matter if they are in one file or multiple ones. I much prefer each “section” of code if you will having a specific name/location I can associate it with, than scrolling as a mad-man. Yeah, I know about markers/closable functions/opening multiple sections of the same file/etc, but at that point whose workflow is more complex?

> I see your point, but no one uses Windows notepad for coding anymore.

Did I miss an IDE that inlines all those things for you automatically? Because ones that only give you a "jump to definition", or maybe a one-at-a-time preview in a context popup, are not much better than Notepad++. You still don't get to see all the relevant things at the same time.

Most real world applications won’t have `print “red”` or the like under a specific implementation. Good luck inlining 6 1000 lines-implementations into a single switch statement.

The "project" vs. "external" vs. "system" library conceptual distinction exists for a reason. But of course you want presentation-level inlining to be semi-automated, much like autocomplete and jump to definition.

I didn't watch the video but I read the article and in the later part he shows how to extend every versions (polymorphic, enum and table-based) to "computing the sum of the corner-weighted areas".

This extension is easy enough with in the non-pessimistic case (table based).

> Main selling point of clean code - the objective of writing clear maintainable, extendable code

That's the alleged selling point, whether even that's true is arguable.

Since while performance can be clearly measured - whether the given "clear code" principles do in fact help with writing "maintainable and extendable code" is something that can be argued back and forth for a long time.

Reply on news.ycombinator.com