# Kernighan and Ritchie (or K&R) and Other Coding Standards Discussion.

This topic is 4075 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I don't know why but alot of the stuff in the K&R coding standards seem wierd to be and wanted to get your guys opinions. I will just go through each section that i disagree which. Naming: K&R : "A variable or function name should be sufficient to understand the meaning, while remaining concise. The shorter the lifespan or scope of a variable, the shorter its name should be; conversely, the more important a variable, and the more places it is used, the more descriptive that name should be." I really don't think naming a variables shorter if it is not used as much is really a good idea. I mean K&R sytle would have a variables named nelems which if i where jsut to look at that, I would be a little confused and would not know what it mean right away but I would name the name variable number_of_elements and to me that is much more clear becuase i knwo right away that it is the number of elements(i may not know what elements it is referring to but I would just need to look at the code around quickly, alot wuicker then i would if i needed to figure out what nelems means). Indentation and Spacing: This is the example on how to do it K&R style:
for (i=0; str != '\0'; i++) {
if (str == ' ') {
if (strcmp(&str[i+1], "static") == 0) {
...
}
else {
if (strcmp(&str[i+1], "final") == 0) {
...
}
}
}
}


And this is how I would do it:
for(i=0; str != '\0'; i++)
{
if(str == ' ')
{
if(strcmp(&str[i+1], "static") == 0)
{
...
}
else
{
if(strcmp(&str[i+1], "final") == 0)
{
...
}
}
}
}


For me, my way just seems alot clearer and cleaner. The major issue with K&R way is when I see major nested if statements. I have see some if statements that written in the K&R style, I just don't know where any if statement ends just by looking at the code but my way I can clearly see it. Another thing is the space between the statement and the parameters like if () seem like a waste of a space to me, it do not do anything good for the reading of the code. Comments: I for the most part agree with K&R. Other Things I See That I Am Not Sure If It Part Of K&R: One common thing i see is when declaring variables/function/classes they are declared like firstFunction, secondFucntion, firstVariable, secondVariable. For me the way I declare variables/function/classes are all different so i know which is which just by looking at the name. I declare variable in all lowercase and underspace for spaces, I declare function which all words first letter capped, and i delcare classes like function just with a 'C' in front of it. also when i declare a class variable i like to add "_object" to the end of it becuase that way i know it is a object just by looking at it. Also with any members(class variables), i use a underscore infront of it that way i know when i am dealing with member inside fo a class function if i happen to have a parameter that is the same name(usually with Set functions). Here is an example of all that.
//variable
int test_variable;

//function
void function DoSomethingFun()
{
}
//class
class CFile
{
public:
void SetTest(int test)
{
_test = test;
}

private:
int _test;
};

//sorry my c/cplusplus is a bit rusty becuase i have been doing php for the pass 1-2 years
CFile file_object = new CFile;


You guys disagree with me on any of these points, just like to know what you guys code standards are.

##### Share on other sites
My coding standards match whatever the coding standards are of the project I'm working on. Period.

If it's a personal project, then I'll pick whatever set of standards I prefer at the time and stick with it. I have different coding standards for different projects - it really doesnt matter what style you use.

##### Share on other sites
Indentation, case, format, bracket placement, comment placement: I don't care. I can read all of them with equal ease, I can write all of them with equal fluency, and most of these can be transformed by automatic tools anyway. Just use the same throughout the code.

Variable naming: one-word names whenever possible. Two-word names if necessary. Three-word names should have a very strong justification. The vocabulary in a project should be as small as possible, with the common abbreviations where useful (numMatches). I use no correlation between the name of the variable and its scope.

Setters: I consider these to be prime indicators of bad design (not bad coding practices). Less than 1% of my classes need even a single setter.

Warts: I am guilty of the foo_t wart at the end of my types, especially when they are template arguments, because emacs likes them (for syntax highlighting). I also use the this-> prefix to indicate member variables and functions where ambiguous to the reader (which is in all ways superior to the underscore prefix). I don't use any other warts in my code, because they don't provide me with any other information I would want. In particular, I find no need for the _object suffix, since (with very few exceptions) all my variables represent objects anyway. Perhaps I should consider a _not_object suffix? [grin]

##### Share on other sites
Kernighan and Ritchie's book was first published in 1978 and then again in 1988 [1]. The 1988 edition was supposedly an update in light of the C89 specification. Since then the C99 specification has been issued but K&R haven't issued an updated book. So if your style isn't like their style, don't worry about it.

##### Share on other sites
Quote:
 Original post by RyanZecI don't know why but alot of the stuff in the K&R coding standards seem wierd to be and wanted to get your guys opinions. I will just go through each section that i disagree which.

vi not emacs

cpio not tar

Atari not Amiga

Beta not VHS

Sheesh, kids today. Gettin' so's it's too easy to start a religious war.

##### Share on other sites
template<    typename foo,    int n  >void bar( foo f ) {  if (f==n) {      // ...  } else if (f==2) {      // ...  }  switch (f()) {    case alpha: {      // ...    } break;    case beta: {      // ...    } break;    default: {      // ...    } break;  }}void baz(    error* err,    space* contained_space_,    dimension* dim_,    int count, int width, int height,    logger* log = 0, tracker* track=0  ){  // ...}template< int n >struct worker:   public virtual slave,   public virtual charlie,   public virtual reference_count{  public:    // ...  private:    // ...};template<int n> worker<n>* clone(worker<n>* inp) {return inp->clone();}

But really, style is what looks good and is clear.

##### Share on other sites
From where I stand, what matters most is that the style for a given project be logical and consistently applied. Details are just that.

If your looking for what others like:

- I prefer CamelCase for word breaks in function and variable namin
- Newlines for blocks. I agree, it's easier to read. I don't agree on the nesting. If you do see several levels of nesting, you should probably be refactoring that code.
- Verbose variable and function names. It's a good way to gauge if something needs to be refactored if it's called DoThisThenThatAndThatOtherThing(10 parameters). I don't agree with K&R's rule of scope. I name things for what they do.
- I use m_ to denote class members, HOWEVER
- For prefixing of variable names, you might do well to do some reading up on Systems Hungarian vs Apps Hungarian and the various pitfalls both can imply. Joel has a pretty complete overview and a practical argument for Apps hungarian here . I like the use of prefixes to indicate scope, but for the most part I've decided against prefix notations. They make things look untidy, can prove a hassle for refactoring, and don't provide enough of a benefit in a strongly typed language to be worth it to me.

##### Share on other sites
I go for K&R style blocks because:

1) I can read them just as easily as your other style (which I used to use).
2) It involves marginally less typing (alright, VERY marginally)
3) The only real reason - I can get a good deal more code on screen, which I find really does make seeing what's going on easier.

##### Share on other sites
The second line bracket style, which I prefer myself, is called the BSD/Allman style. Check the following wiki page for more info.

http://en.wikipedia.org/wiki/Indent_style#BSD.2FAllman_style

##### Share on other sites
Quote:
Original post by Bregma
Quote:
 Original post by RyanZecI don't know why but alot of the stuff in the K&R coding standards seem wierd to be and wanted to get your guys opinions. I will just go through each section that i disagree which.

vi not emacs

cpio not tar

Atari not Amiga

Beta not VHS

Sheesh, kids today. Gettin' so's it's too easy to start a religious war.

I've never even *heard* of cpio, so I guess you're showing your age ;)

Quote:
 Teh OPI really don't think naming a variables shorter if it is not used as much is really a good idea.

Try framing it the other way. Wouldn't you want to name a variable *longer* if it's used *more*? Or more precisely, has a wider scope? After all, bigger scopes = more symbols potentially hanging around to conflict, so you want longer names to reduce the chance of conflict. Also to *emphasize* them; things in a wider scope represent values that need to be *remembered* for some reason; and that typically means they're more *important*. So of course they should have a longer name - an honourary title.

"nelems" is horrible, though. "element_count" reads much more cleanly. Just "count" is a way to shorten that (especially if it's clear what's being counted). IMO, don't use "number_of" (or numberOf or however you want to spell it); "count" conveys the same information more easily.

Quote:
 For me, my way just seems alot clearer and cleaner.

Many will disagree. What "seems" to be is what you should go with for your own stuff; de gustibus non disputandum est. If you're given a coding standard, do try to follow it.

Quote:
 I have see some if statements that written in the K&R style, I just don't know where any if statement ends just by looking at the code but my way I can clearly see it.

How do you "see" it? By lining up the { with a } in the same column, right? Users of K&R style "see" it by lining up the 'if' keyword with a } in the same column. Same thing, really.

I personally pack things in even closer than K&R (i.e. I "cuddle" elses), because it "looks right" to *me*. Again, de gustibus non disputandum est.

Quote:
 Another thing is the space between the statement and the parameters like if () seem like a waste of a space to me, it do not do anything good for the reading of the code.

This sounds inconsistent. A space after a keyword is "wasted space", but a whole separate line for a { character is "useful"?

(I *do* feel fairly strongly about this one. The reason for putting spaces after if/for/while/switch is to distinguish them visually from function calls. I don't particularly like having to rely on syntax colouring to tell that at a glance.)

1. 1
Rutin
25
2. 2
3. 3
4. 4
JoeJ
18
5. 5

• 14
• 14
• 11
• 11
• 9
• ### Forum Statistics

• Total Topics
631757
• Total Posts
3002141
×