On 1/6/2014 6:46 PM, 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.
Side-by-side diffs are one use case I can think of. Another is that some
people prefer to develop by keeping tiled copies of windows; wider lines
reduce the number of tiled windows that one can see. People who use
terminal-based editors for their coding are probably going to be rather
likely to use the default window size for terminals: 80x24. Given that
our style guide also requires adding vim and emacs modelines to files
(aside: if we're talking about doing mass style-conversions, can we also
fix modelines?), it seems reasonable that enough of our developers use
vim and emacs to make force-resizing of terminal size defaults a
noticeable cost.
With 2-space indent, parsimonious indenting requirements (e.g., don't
indent case: statements in switch or public in class), and liberal use
of importing names into localized namespaces, the 80-column width isn't
a big deal for most code.
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.
And a '_' at the end of member names requires less typing than 'm' +
capital letter?
My choice of when to use or not use Hungarian notation is often messy
and seemingly inconsistent, although there is some method to my madness.
I find prefixing member variables with 'm' to be useful, although I
dislike using it in POD-ish structs where all the members are public.
The use of 'a' for arguments is where I am least consistent, especially
as I extremely dislike it being used for an outparam return value
(disclaimer: I'm used to XPCOM-taminated code, so having to write
NS_IMETHODIMP nsFoo::GetBoolValue(bool *retval) is common for me, and
this colors my judgements a lot). I've never found much use for the 's',
'g', and 'k' prefixes, although that may just as well be because I've
never found much use for using those types of variables in the first
place (or when I do, it's because I'm being dictated by other concerns
instead, e.g., type traits-like coding or C++11 polyfilling).
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
