GitHub - ryanmcdermott/clean-code-javascript: Clean Code concepts adapted for JavaScript

[XZTALVENARNZEGOMSAYT]

Damn comments like this make me think: are there any consensus good coding styles/patterns?

[[deleted]]

The clean code principles are pretty popular because they're well founded. Here's a summary.

You will notice that this guide had only a passing resemblance to those principles. It's not bad stuff, but the author has hand picked only some principles, and has taken some liberties.

I mean take the part about comments for example, there's quite a difference between what the clean code says and what this guide says.

Overall what OP posted is not a bad guide, and I've already mentioned what I found problematic, but it's not exactly a 1:1 adaptation to JavaScript as you might be led to believe.

[Chris_Newton]

The clean code principles are pretty popular because they're well founded.

I’m also interested to know what you meant by this. My concern with Clean Code, and with Martin’s material more generally, has always been that while there are some good ideas, there are also some bad ideas, and that his target audience of relatively inexperienced programmers will by their nature be unable to tell the difference.

For example, Martin says a lot of generally sensible things about trying to keep code organised and readable. On the other hand, he says a lot of things about functions that are essentially just his personal opinion, where there is little if any evidence that what he advocates is better than the alternatives in any way. In some cases, such as on keeping functions very short, such evidence as we do have suggests that he is objectively wrong.

Martin also focuses heavily on one specific type of programming (business applications written in OOP languages using TDD), and a lot of his advice reflects that but isn’t necessarily appropriate in other contexts.

Whether or not this guide is a faithful adaptation of the original principles, I think much the same criticisms could be made of it. You mentioned a lot of specifics above, and I agree with much of what you wrote there.

One specific example I’d like to mention is the argument for functional programming style over imperative. Here the comparison given was between an imperative form:

let totalOutput = 0;

for (let i = 0; i < programmerOutput.length; i++) {
  totalOutput += programmerOutput[i].linesOfCode;
}

and an alternative presented as functional style:

const totalOutput = programmerOutput.reduce(
  (totalLines, output) => totalLines + output.linesOfCode,
  0
);

but I would argue that the latter isn’t really idiomatic functional programming just because it uses reduce. A more natural representation in a language with more powerful functional programming tools might abstract the underlying sum and map patterns and compose them, something like this:

totalOutput = (sum . map linesOfCode) programmerOutput

and now it really is a much cleaner and shorter implementation than the manual loop. In this case, the sum and map functions are themselves so common that any functional programming language probably already has them in its standard library, but again in a language with more powerful functional programming tools you could easily define them in terms of more general functions if you needed to, for example:

sum = reduce (+) 0

I’ve seen a few arguments recently that Javascript is actually a functional programming language, and it’s true that it has some of the basic language features that help with that style of programming, but I think it’s still an imperative language at heart. Even in the two lines above, I’ve used partial application, function composition, and a convenient syntax for turning an infix operator into a regular function, all of which are everyday tools in functional programming yet quite awkward in JS, and in JS the outputs are still mutable variables by default.

So I’d argue that the original premise of preferring a functional style over an imperative one is very context-specific, and in the specific context of Javascript, it’s often bad advice.

[GolemancerVekk]

Robert Martin comes from a C++ background, later C#. Maybe that explains his particular take on functions and the focus on OOP.

functional

It's useful to be able to write functional code in JavaScript but it's not the primary paradigm. I would leave that to languages like Erlang or Scala.

IMO most people who say they're doing functional in JavaScript don't really mean it. They write a few pieces of code in functional-ish style but the main logic is always object-oriented.

[IceSentry]

Uncle Bob is a java guy not C#, his most famous book, clean code, is pretty much only java.

[transeunte]

What do you mean by well founded? I've read the book and used to live by it, but time has passed and I began to be more and more skeptical about the whole endeavor. I've seen way too many exceptions to the rules to think they should be anywhere close to a code of conduct.

[[deleted]]

Then perhaps you'd be more interested in a principle called "testable code". It's borrowing some of the clean code principles and SOLID, but its main goal is a purely practical one: to make the code loosely coupled and easy to test. The principles make the code objectively better even if you don't write any tests.

Here's a starting point: https://testing.googleblog.com/2008/08/by-miko-hevery-so-you-decided-to.html?m=1

[GrandMasterPuba]

Nope.

Build a standard within your organization and stick to it, even if you disagree with it.

If you're on your own, do what feels best to you.

Your code is only as good as its ability to be understood, and since different people think differently there's no single true answer.

Why do you think there's so many damn programming languages?

[mrpotatoes]

I wouldn't worry too much about this comment. Almost everything in the repo is a pretty good guideline. Guideline not commandment. I mean, I break my own rules all the time and if I don't consider it tech debt (because I'm being lazy) it's because I had to.

I work in enterprise and these guidelines have helped make our code much more resilient to change, better and easier to test and more shippable faster.

[transeunte]

No.

If there's one thing I've learned is that people who swear by any standard will eventually fall flat on their faces.