I am in particular agreement with the "don't edit working code to conform with style" in the compiler and perhaps in compiled languages in general. However in languages that are interpreted, often the interpreter will accept really bad or even erroneous code which will fail to execute (but only if tests exercise the code). In particular, JavaScript is a language easily abused. Running JSHint on the source is the closest thing we have to a "compiler". For this reason I would like to see all checkins for Node and JavaScript produce a clean JSHint report. This implies some code guidance which is certainly stylistic (requiring semicolons where they are actually optional, etc.). Also, in the case of Python, indentation is critical, having one definition for an indent seems fairly rational, though the interpreter does not always care.
In summery I agree in spirit with most of the foregoing but I think we do need to provide style guidance in several libs where it adds value and reduces the potential for defects. -Randy On Fri, Sep 26, 2014 at 9:33 AM, Jens Geyer <[email protected]> wrote: > That was exactly what I felt. > ________________________________ > Von: Rush Manbert > Gesendet: 26.09.2014 17:44 > An: [email protected] > Betreff: Re: C++ coding standards > > I think this veers off into territory that should be avoided for this project. > > I am not against having coding standards. Not at all. But Thrift is a fairly > mature product. Disregarding new language support, I suspect that the bulk of > the future coding required will be bug fixes. If that is true, then the best > thing to do is to preserve the style that you find in the code you are > modifying. The last thing I would want to see is that someone fixes a bug in > the compiler or adds a new feature and uses a style totally foreign to what > was originally used. > > When I delve into the compiler code I remember that it has its peculiarities > and my mind shifts into "compiler dev mode". If I look at the library code I > gradually shift into "library dev mode". Neither of those are what I prefer > or dictate when I set the coding standards, but they maintain the original > style. That's a good thing. And Heaven forbid if coding standards are written > and someone decides to change existing code to conform to them. You do NOT > change working, tested code just because you don't agree with its style. > That's just asking for problems. > > I don't usually play this card, but I am speaking from 42 years of experience > writing software. I feel that you're just going to waste time and effort. > > That's my 2 cents, for what it's worth. > > - Rush > > On Sep 26, 2014, at 6:28 AM, Ben Craig wrote: > >> I haven't seen any explicit coding standards. I have a minor preference >> for using whatever the "local" style already is, but it isn't a large >> concern of mine. >> >> Konrad Grochowski <[email protected]> wrote on 09/26/2014 08:03:45 AM: >> >>> From: Konrad Grochowski <[email protected]> >>> To: [email protected], >>> Date: 09/26/2014 08:04 AM >>> Subject: C++ coding standards >>> >>> Hey, >>> >>> Are C++ coding standards for thrift defined anywhere? I see that lib/cpp >> >>> looks like this 'ClassName::methodName' but compiler code look more like >> >>> 't_class_name::method_name'. I definitely prefer first style, but >>> currently I'm playing around compiler. Can I use 'lib' style, assuming >>> that's more recent and compiler code will move toward that look? >>> >>> -Konrad >
