On Mon, Jan 6, 2014 at 5:38 PM, L. David Baron <dba...@dbaron.org> wrote: >> > 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.
SpiderMonkey's used 99 for years and years without anyone (AFAIK) arguing that it be increased again. So I think that's a needless concern. One thing to mention: SM uses 4-space indents, and that makes the 99 char limit more of a win that it would be with 2-space indents. One annoying thing about SM is that *code* is allowed to be 99 chars, but comments are not supposed to exceed 80(!) This is kinda awful because you can't set up an editor (AFAIK) for both. I settled on setting my editor for 80 chars and then I manually unbreak longer lines (ugh). > On the flip side, I strongly dislike the JS style in which member > variables and constructor arguments frequently shadow each other. A trailing '_' (e.g. foo_) is sometimes used in SM for members. This helps reduce shadowing, but isn't sufficient, even if it's applied consistently. (I've beaten my head against this numerous times trying to enable -Wshadow, and failed every time.) I found the gFoo/sFoo/aFoo/mFoo style bizarre at first, but have come to prefer it. > 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. It's pretty darn common to have a blank line after an indented block, in which case it doesn't end up wasting space. Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
