Back to General and Gameplay Programming

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

General and Gameplay Programming Programming

Started by RyanZec May 03, 2007 11:21 AM

17 comments, last by kRogue 16 years, 10 months ago

RyanZec

124

Author

May 03, 2007 11:21 AM

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.

Colin Jeanne

1,115

May 03, 2007 11:32 AM

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.

ToohrVyk

1,596

May 03, 2007 11:35 AM

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]

Blog — Facebook

LessBread

1,415

May 03, 2007 12:06 PM

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.

"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man

Bregma

9,461

May 03, 2007 03:53 PM

Quote:Original post by RyanZec
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.

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.

Stephen M. Webb
Professional Free Software Developer

NotAYakk

876

May 03, 2007 04:36 PM

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.

Valere

248

May 03, 2007 04:44 PM

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.

ZQJ

496

May 03, 2007 05:06 PM

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.

Inmate2993

222

May 04, 2007 12:06 AM

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

william bubel

Zahlman

1,682

May 04, 2007 01:47 AM

Quote:Original post by Bregma
Quote:Original post by RyanZec
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.

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 OP
I 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.)

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

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

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

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines