-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Förster wrote: > Am Dienstag 03 Juli 2007 10:31 schrieb Martin Spott: >>> Perhaps you recall this thread: "C++ code beautifier / >>> Codingstandardsproposal" >>> >>> Seems to me that we are just revisiting these issues. >> I can't remember having read a proposal that found general consensus in >> the mentioned thread - so I consider the whole claim as void, > > I got no response to my draft proposal, which I read as nobody cares. So you > possibly might safely ignore any complaints. > > Thomas
I read it, and I wouldn't say that I don't care, but there are plenty of things about which I care more. I didn't write a critique because some parts are not part of an enforceable coding standard, some parts I agree with, other parts I disagree with... and I know that those who care more passionately than I would never allow the parts I disagree with :) > File Naming > ----------------- > All filenames are all lower case. Header files end with the suffix .hxx, code > files get the prefix .cxx. (Preferably?) The filename is just the class name > that is defined therein, accordingly suffixed. (Preferably) Only one class is > defined per file. > I agree that file names should follow class names, and strongly disagree that their case should be different from the class. The current code base is pretty random about this. > Class names > ------------------ > Class names generally are nouns that communicate the function of the class. > No > prefixes are used. Class names begin with an uppercase letter. > > NOTE: Currently there are a lot of prefixes like FG... I don't see the need > for them as that's what namespaces are for. > Pretty standard stuff. I strongly agree about namespaces. It's now 2007... I'm annoyed that my limited attempts to use namespaces were deleted from patches I submitted :) Really, the SG and FG all over the place are distractions. > Function naming > ----------------------- > Function names begin with a lowercase verb expressing clearly what the > function does, probably followed by further specifications. Can't argue with that :) > Variables > ------------- > The names of private attributes of a class begin with an underscore followed > by a lowercase letter, i.e. _pitch, _altitude > > Rationale: > If applied consistently for only this purpose, the underscore instantly > communicates the variable at hand as being private to the class. I personally hate underscores or any other indication that a variable is a private member, with the rationale that a cursory reading of a well-written class will quickly give you that information anyway, but I know that the guardians of coding taste disagree with me. > Braces > ---------- > Opening braces are on the same line as the preceding statement (function > declaration, if clause, etc.). Closing braces follow a newline and are > properly indented to align with the block they close. > I mostly agree, except for function definitions. That is just not a very widespread style. > Indentation > --------------- > The code uses 4 spaces for indentation. > > Rationale: > As tab size is dependent on personal configuration and therefore > unpredictable, only spaces are allowed to indent code blocks. 4 spaces is a > compromise between readability and screen space used. > Agreed, and I don't have much sympathy for those who want to view the code with some other indentation. Anyway, if you're going to adopt a coding style, you might as well adopt one that is familiar to most practitioners of the language, as is the one described here. However, it's easy to overestimate the importance of a uniform coding style. Experienced developers must adapt to different styles in course of their work, and this is not difficult as long as individual files or "modules" are written in a good, consistent style. It is surely in terrible taste to start coding away in a file in a different one from the one that already exists there, even if the new style is the "official" one. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGiiUFeDhWHdXrDRURAnhPAJ4xPD3g3MRM1SEGMQMX6UEbNYFUBACghCr9 i+xDg9HTnf0KzvKEmIBVJCU= =OE7n -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
