The Big Javascript Style discussion

[hackathi]

Hi all,

after educating myself a bit and reading the three popular style guides – AirBnB, google and standard – I want to get other peoples opinons.

Personally, I disagree with so much in standard, that I don't see it fitting in. Especially list-end-commas and the omission of all semicolons aren't really what I like.

For me, AirBnB seems like a good start, but still needs changes:

• 7.15 wrapping anything should align with whatever's above to not introduce visual clutter.
• 11.1 should be reversed; prefer list iterations over higher oder functions whenever possible. This is more in line with php conventions.
• 16.2 I dislike the super ultra condensed brace style, as there is no clear block seperation. I'd like to stay at Allman or switch to Stroustrup. I have this issue with PSR-12 as well.
• 19.1 I'd like 4 spaces per indentation level across the whole repository. I have seen other projects struggle with enforcing tabs; as far as I'm aware there is no reasonable eslint prefix to have a "tab to indent, space to align" setting which is the only reasonable way to use tabs that keeps the benefit of reconfigurable tab sizes. For simplicity, I'd argue to settle on four spaces per indent level, and use spaces for everything. They will be removed by uglifyjs anyways.
• 24.2 and the reasoning behind it are personal preference from the author of the AirBnB guide which I disagree upon. They need some oversight on review and shouldn't have complex side effects, but the whole argument around not allowing them seems to be based around "they have side effects" which is the whole point. So, instead, I'd like to disallow getX() and setX(value) functions but use getters and setters.

Google needs a bit less adjusting, but I still disagree with the K&R braces, indentation and getters and setters; and also needs adjusting of object-curly-spacing. I'd also like to prefer deconstructing and object shorthands.

What are your thoughts?

[mohe2015]

Hi all,

after educating myself a bit and reading the three popular style guides – AirBnB, google and standard – I want to get other peoples opinons.

Personally, I disagree with so much in standard, that I don't see it fitting in. Especially list-end-commas and the omission of all semicolons aren't really what I like.

For me, AirBnB seems like a good start, but still needs changes:

• 7.15 wrapping anything should align with whatever's above to not introduce visual clutter. ✔️

• 11.1 should be reversed; prefer list iterations over higher oder functions whenever possible. This is more in line with php conventions. ❌ I personally think a functional style is benefical even if php doesn't go that route (or we would need to change that).

• 16.2 I dislike the super ultra condensed brace style, as there is no clear block seperation. I'd like to stay at Allman or switch to Stroustrup. I have this issue with PSR-12 as well. ✔️ I don't have a strong opinion on that but either is fine.

• 19.1 I'd like 4 spaces per indentation level across the whole repository. I have seen other projects struggle with enforcing tabs; as far as I'm aware there is no reasonable eslint prefix to have a "tab to indent, space to align" setting which is the only reasonable way to use tabs that keeps the benefit of reconfigurable tab sizes. For simplicity, I'd argue to settle on four spaces per indent level, and use spaces for everything. They will be removed by uglifyjs anyways. ✔️ For me 2 would be enough but 4 is also fine.

• 24.2 and the reasoning behind it are personal preference from the author of the AirBnB guide which I disagree upon. They need some oversight on review and shouldn't have complex side effects, but the whole argument around not allowing them seems to be based around "they have side effects" which is the whole point. So, instead, I'd like to disallow getX() and setX(value) functions but use getters and setters. ✔️ with the restriction of not having heavy side effects I'm fine with that.

Google needs a bit less adjusting, but I still disagree with the K&R braces, indentation and getters and setters; and also needs adjusting of object-curly-spacing. I'd also like to prefer deconstructing and object shorthands.

What are your thoughts?

[hackathi]

I personally think a functional style is benefical even if php doesn't go that route (or we would need to change that).

It is absolutely not standard in any php codebase I came across in the last 10 years. But then again, I have my doubts that many programmers of those codebases could even explain what a higher order function is, so for php at least – foreach($a as $b) needs to stay.

My main issue with higher order functions is that they are, in my opinion, bad for readability. Consider these code snippets:

for(let i = 0; i < arr.length; i++) {
    let elem = arr[i];
    /* do something with elem */
}

for(const elem of arr) {
    /* do something with elem */
}

arr.forEach((elem) => {
    /* do something with elem */
}

The first two examples make the intent (exercising a loop) extremely clear. I don't feel the same about the higher order function. This very well may be that I'm just not used to it – I mainly program C, C++, C#, python.

And I do see the benefit of using higher order functions when appropriate:

arr.forEach(elem => elem.fooBar = 42);

function applyStuff(method) {
    this.someArray.forEach(method);
}

But using them as an end-all be-all is such a foreign concept to me, that I really struggle to understand why these are so popular within javascript. The best explanation I could come up with is that for .. of and for .. in have only recently become a thing, and you just didn't have a choice but use higher order functions. But thats no longer the case.

So probably my stance on this should be: Use higher order functions when it improves readabilty (e.g. if your loop would just apply a function to every element anyways), but use loops everywhere else.

Real-world example (js/components/barcodescanner.js):

result.boxes.filter(function (box) 
{
    return box !== result.box;
}).forEach(function (box) 
    {
    Quagga.ImageDebug.drawPath(box, {
	    x: 0,
	    y: 1
    }, drawingCtx, {
	    color: 'yellow',
	    lineWidth: 4
    });
});

is much more clearly expressed this way:

const boxes = result.boxes.filter(box => box !== result.box);
for(const box in boxes) {
    Quagga.ImageDebug.drawPath(
        box, 
        { x: 0, y: 1 }, 
        drawingCtx, 
        { color: 'yellow', lineWidth: 4 },
    );
}

There are two parts to this: first, the forEach call in the current code is badly formatted in the first place. But even a reformat doesn't make it as clear in my opinion – forEach still gets "bolted on", so I need to remember what I work with over more lines, and also needlessly increases indentation level.

result.boxes.filter(box => box !== result.box)
    .forEach((box) => {
        Quagga.ImageDebug.drawPath(
            box, 
            { x: 0, y: 1 }, 
            drawingCtx, 
            { color: 'yellow', lineWidth: 4 },
        );
    }
);

Removing the "bolting on" helps a little:

const boxes = result.boxes.filter(box => box !== result.box);
boxes.forEach((box) => {
        Quagga.ImageDebug.drawPath(
            box, 
            { x: 0, y: 1 }, 
            drawingCtx, 
            { color: 'yellow', lineWidth: 4 },
        );
    }
);

But still doesn't signal intent as clearly. for is a keyword, forEach is a method. for benefits from syntax highlighting, forEach does not (at least in github and also not in VS Code, my primary editor).

[mohe2015]

I agree for php but I also think that many people haven't realized the advantages of higher order functions. Look at Rust which does an impressive job at creating readable but extremely efficient code (e.g. https://doc.rust-lang.org/book/ch13-02-iterators.html#using-other-iterator-trait-methods last example - I admit you need to get used to it a bit).

I also agree that forEach isn't the best higher-order function. So I think for loops are totally fine just filter and map are nice especially if you can apply them to a function directly. reduce is not so easy to understand and usually not worth it but it depends. Still there may be cases where filter or map may not be useful but I think we will find the sweet spot when reviewing and writing a bit of code. We can always reevaluate this in my opinion.

[hackathi]

I'm fine with filter, map and reduce. Thinking about it, I just have a problem with forEach. The rest are fine, I wouldn't use a loop to express those things.

We could settle on strongly discouraging .forEach(), which is my main grievance here.