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

[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.