On 01/06/2014 06:35 PM, Joshua Cranmer 🐧 wrote:
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.
Yes--if we jump to >80 chars per line, I won't be able to keep two
columns open in my editor (vim, but emacs would be the same) on my
laptop, which would suck.
(Yes, my vision is not what it used to be--I'm using 10 point font. But
that's not so huge.)
Jason
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).
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
