On Monday 2014-01-06 18:46 -0600, Jeff Walden wrote: > I'm writing this list, so obviously I'm choosing what I think is on it. But > I think there's rough consensus on most of these among JS hackers. > > JS widely uses 99ch line lengths (allows a line-wrap character in 100ch > terminals). Given C++ symbol names, especially with templates, get pretty > long, it's a huge loss to revert to 80ch because of how much has to wrap. Is > there a reason Mozilla couldn't increase to 99 or 100? Viewability on-screen > seems pretty weak in this era of generally large screens. Printability's a > better argument, but it's unclear to me files are printed often enough for > this to matter. I do it one or two times a year, myself, these days.
My argument against it is that there's a clear standard around 80ch since it's a longstanding terminal width, and if we start increasing the width, it'll keep increasing. People need to get an editor and terminal setup that works with the widest code they work with. However this works, it'll likely be able to deal with something a little bit wider than needed. Good enforcement of a defined standard does reduce the risk of creep due to this problem, but it doesn't reduce the chance that somebody will come along next year and ask for 120, etc. So if we're switching to 99 or 100, I'd like to understand how you picked that number and have confidence that it's not just going to keep going up. I'm also concerned about what happens as we get older and have poorer vision. I tend to think that we should either: * stick to 80 * require no wrapping, meaning that comments must be one paragraph per line, boolean conditions must all be single line, and assume that people will deal, using an editor that handles such code usefully > I don't think most JS hackers care for abuse of Hungarian notation for > scope-based (or const) naming. Every member/argument having a capital letter > in it surely makes typing slower. And extra noise in every name but locals > seems worse for new-contributor readability. Personally this doesn't bother > me much (although "aCx" will always be painful compared to "cx" as two no-cap > letters, I'm sure), but others are much more bothered. On the flip side, I strongly dislike the JS style in which member variables and constructor arguments frequently shadow each other. I'm fine with switching here, as long as it's *to* something that doesn't yield this sort of shadowing. > JS people have long worked without bracing single-liners. With any style > guide's indentation requirements, they're a visually redundant waste of > space. Any style checker that checks both indentation and bracing (of course > we'll have one, right?), will warn twice for the error single-line bracing > prevents. I think most of us would discount the value of being able to add > more to a single-line block without changing the condition line. So I'm > pretty sure we're all dim on this one. I prefer non-bracing visually, but I've found the bracing to be useful often enough when inserting debugging-printfs that I've come to prefer it even though I think it's ugly and wastes space. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
