Jump to content
  • Advertisement
Sign in to follow this  
RyanZec

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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
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.

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
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.)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!