Hacker News new | ask | show | jobs
by zelon88 1877 days ago
I think it's ironic that the author claims that clean code is.......

  Package your code down into small, atomic and reusable units
  Follow the single responsibility principle
  Use frameworks and libraries to avoid reinventing the wheel
  Whatever language you pick, don’t pick PHP
These are best practices. It is possible to follow every one of those rules and still have a pile of broken, insecure, garbage code. Likewise you can have a very elegant one-liner that fits none of those and gets a job done cleaner and easier than any alternative. You can even have a single page app that fits most of those, and I would argue that it would probably stay cleaner without adding a framework. Frameworks in many ways bind you to a certain style.

It's all about keeping the scope of what you're doing in mind and using the correct tool for the job. Saying "this tool is better for every job" is going to get you a lot of arguments.

Also, with the exception of the third bullet point, you can follow all of those practices and still fit your app into a single file. There is nothing more frustrating than working on a codebase that puts 12 lines of code in each file and then spreads that code into 1,000 files.

And the final bullet point in regards to PHP is just false. But I digress.

3 comments

That's partly the reason why the term "best practice" has become a bit controversial in some communities --- it's seen as mindless dogmatic cargo-culting. I've heard the saying "best practices are best not practiced" from the opposition.

There is nothing more frustrating than working on a codebase that puts 12 lines of code in each file and then spreads that code into 1,000 files.

In other words, "Enterprise" code, which is in my experience usually designed more to hit all the "best practices", and often according to the opinion of some idiotic tool (as in computer program, although sometimes a person too...), than do anything sanely.

If you are having difficulty navigating a project because it has many modules, I really don't think that is an argument for disavowing whatever best practices. Rather, it is more of an argument against whomever organized the code base in a way that they like and you don't.
This gave me a thought just now. When future changes are needed to a piece of software, these are usually driven by the business side.

If the original developers have moved on, and the current developers do not have a good handle on the software, there could be some troubles making changes.

What if we approach the problem by structuring the code and choosing names to better reflect the business terminology. Make it such that a business person could understand the software at high level.

Then years later, it becomes much easier for a new set of developers work with the business side to make enhancements and changes.

Given the drift of the article, as signalled by its title, I think this precis of 'clean code' was being presented sardonically - particularly that last point. As you point out, you can nominally follow all these rules and still not squeak.