Live data from Hacker News

Maintainable JavaScript (2014)

alexkras.com

31–33 of 33 posts

Re: Maintainable JavaScript (2014)

#32
The way I evaluate if a recommendation is good or bad is how it filters bad code.

The 4 most important things for me to keep under control are:

1) Length

2) Cyclomatic complexity

3) Shared mutable state

4) Coupling

If you keep those under control, the rest of the maintainability will come by itself. e.g: testability, reusability, thread safety, security and other high level goals are easier when these low level requirements are met.

And, of course, consistency. Make sure that things do what they say they do. e.g: make sure the purpose of a variable or function can be explained only through its signature without requiring to look at the code.

Re: Maintainable JavaScript (2014)

#33

Earlier quoted context omitted.

No. Using a weak, dynamically typed language adds complexity. Using a compiler isn't adding complexity.

Except the transpiled code is still dynamically typed. People act like when they started writing Typescript they stopped writing bugs..

First, they don't act like that, and if they do that's dumb.

Second, how is that different from writing in a statically-typed language like Haskell/Rust/what have you and then compiling down to assembly which is for all intents and purposes dynamically typed? We do it hoping to gain safety from the typing, but do we lose the type safety in the machine code? (We don't, the type-safe language rules out compiling to certain classes of erroneous code.)

Post reply on HN