I agree that editing code only to match changed coding standards is
unnecessary (mostly because it disrupts 'git blame' ;) ), but that
doesn't mean that new parts should keep to old ugly, inconsistent style.
I really believe in importance of constant refactoring and maintenance,
and that means, that after some iterations all code will naturally be
changed into 'new style'.
By coding standards I do not only mean naming convention, but for
example 200 lines functions, which are untestable. In my fork I split
and split and split and introduce low level unit tests. But that changes
the way code looks, yet I'm pretty confident it's a move in good
direction. Developer should never be afraid of making changes to
existing code - tests are there to ensure nothing gonna break. And if
tests do not provide that - then tests needs to be changed, or software
will rot and became unmaintainable. And if style is what is in the way
of tests, then it too should be changed, to provide future for project.
Although I do not like t_style_naming I can live with that, but not with
blob functions and classes.
Regards,
Konrad
W dniu 2014-09-26 18:52, Randy Abernethy pisze:
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
