Forcing code conventions

[cpjust]

But then where do you draw the line? I mean, look at audinue's example again. It's precisely that "whether you put a spaces around an expression inside parentheses" sort of thing. In fact, if you look at most coding guidelines, they're typically just as strict. My contention is that by enforcing such things, the author is either forced to convert all of their work after the fact, or else adopt the standard outright to save time. Neither make sense to me. I would prefer to give people full artistic license so that they can concentrate on more important things rather than to be so concerned with such trifling details.

So then they could write stuff like this, which just ........es off people that have to maintain the code once they're gone?

main(){char o[1920]={0};int _;double l[]={0,-5,11,0,0,5,0,0,0},_1=0.174533;
for(_=0;_<36;++_)(((int)(2[l]=((cos(_1)*(4[l]=2[l]))+(sin(_1)*7[l])))+12)*80
+((int)(7[l]=((cos(_1)*7[l])-(sin(_1)*4[l])))+40))[o]=_<27?(((int)(8[l]=((cos(-_1)
*(6[l]=8[l]))+(sin(-_1)*5[l])))+8)*80+((int)(5[l]=((cos(-_1)*5[l])-(sin(-_1)*6[l])))
+40))[o]=(((int)(1[l]=((cos(_1)*(0[l]=1[l]))+(sin(_1)*3[l])))+16)*80+((int)(3[l]=
((cos(_1)*3[l])-(sin(_1)*0[l])))+40))[o]='*':'*';_=0;while(_<1920)putchar(_++[o]);}

[edit: what's with the word filters on this site? sessip (backwards) is hardly a controversial word]

[brewbuck]

But then where do you draw the line? I mean, look at audinue's example again. It's precisely that "whether you put a spaces around an expression inside parentheses" sort of thing. In fact, if you look at most coding guidelines, they're typically just as strict. My contention is that by enforcing such things, the author is either forced to convert all of their work after the fact, or else adopt the standard outright to save time. Neither make sense to me. I would prefer to give people full artistic license so that they can concentrate on more important things rather than to be so concerned with such trifling details.

I thought I described where I draw the line... Any stylistic convention which could reasonably be argued to enhance code correctness and maintainability is okay with me. The positioning of parentheses don't meet that criterion.

Still, when working on a pre-existing module I tend to follow the style already in place, unless doing so is painful. My only pet peeve is not placing opening braces on a separate line. I'll emulate that style as well for consistency but I don't like it.

[Sebastiani]

>> So then they could write stuff like this, which just ........e's off people that have to maintain the code once they're gone?

Hey, no fair. I had to fit it into 512 bytes.

>> Still, when working on a pre-existing module I tend to follow the style already in place, unless doing so is painful. My only pet peeve is not placing opening braces on a separate line. I'll emulate that style as well for consistency but I don't like it.

I generally conform to whatever standards are being used, too, but it does annoy me that these things aren't handled by software instead. My biggest pet peeve is lack of indentation (ie: one or two spaces per 'tab').

[whiteflags]

There are some excellent solutions to this problem posed already, in the end it comes down to the culture of the classroom and what kind of instructor you want to be. I don't think forcing them to hand in homework in a particular style will break their brains though. Maybe just their fingers.

[Elysia]

Also forcing some particular style upon people is just annoying to them, so that's a bad idea.
They should choose a style, but within some limitations.

[cpjust]

I think proper indenting is the most important thing they should all learn, maybe followed by one statement per line. The rest is more of a personal preference.

[audinue]

Here I comes with new solution...

While they keep asking, "Why my codes error??"
(in this case for syntax errors)

I will just say, "Please read your code loudly!"

Just give up... xD

Nice discussion, thanks.

[VirtualAce]

Since they will most likely have a coding standard placed upon them in the real world I see nothing wrong with docking them for not meeting the classroom's set forth standards. It's not a matter of self-expression or a matter of what they want to do, it's a simple matter of submitting to an authority even when you don't agree with it. Great training for the real world.

I can argue all day long at work why I should or should not code the way we do but if it is against our company standard then it is I who am wrong, not them. It's not about what I want to do or my co-workers want to do it is about what the company wants to do inside their code lines. I do not own them and therefore I simply follow the rules regardless of whether I agree with them or not.

Coding standards are a fact of life and learning to adhere to them early on is very practical job experience.

[cpjust]

I can argue all day long at work why I should or should not code the way we do but if it is against our company standard then it is I who am wrong, not them. It's not about what I want to do or my co-workers want to do it is about what the company wants to do inside their code lines. I do not own them and therefore I simply follow the rules regardless of whether I agree with them or not.

Coding standards are a fact of life and learning to adhere to them early on is very practical job experience.

But that doesn't mean the standards can never change.
In the first place I worked, they talked about changing their coding standards for quite a while, then slowly started making changes.

You can't go against the standards, but you can argue your case for why they should change, and if enough people agree, they might finally see the light and change them.

[VirtualAce]

But that doesn't mean the standards can never change.
In the first place I worked, they talked about changing their coding standards for quite a while, then slowly started making changes.

Very true in a work environment. However for the purpose of this thread I believe enforcing coding standards on students is very good practice for them. And if the business does not agree with your changes to the standard you are definitely not going to continue to do your own thing and expect to keep working there. If they do then chalk it up as a victory. My point is you code to the standards that have been put in place. It was not to imply that coding standards are immutable in a work environment.

[Sebastiani]

I can understand standards in other areas; structure, design, modularity, stability, etc. But this is different matter altogether. Look, a very small percentage of programmers are going to produce completely illegible crap. The rest are generally going to have a very consistent style that essentially models their *actual* thinking process. Interfering with that for the sake of uniformity or whatever is a genuine mistake (and yet so common!). I mean, should an editor reject a great novel simply because the manuscript isn't formatted to his liking? Of course not. They're unrelated issues when you get right down to it. I really think we should encourage personal style. Not only does it foster creativity, but it tends to make people more productive, as well.

[cpjust]

Personal style is fine when the work is personal, but when you're working in a group, the other people have to be able to easily understand your work. Badly formatted code can lead to misunderstanding and possibly mistakes by other less experienced developers.

[Elysia]

There is a fine line between a good code and bad code. Therefore, students shall be taught to write good code, devoid of laziness, yet not forced to build upon one style.
Forcing someone to do it a specific way just is not very nice.

[whiteflags]

Forcing someone to do it a specific way just is not very nice.

Don't get that. You sit them down for a lecture and explain how you want things spaced and where braces go, and explain that they'll have to get used to indent styles in the workplace, and it's over.

I guess you guys are feeling artistically repressed or something. I recommend pencil drawing!

I can understand standards in other areas; structure, design, modularity, stability, etc. But this is different matter altogether. Look, a very small percentage of programmers are going to produce completely illegible crap. The rest are generally going to have a very consistent style that essentially models their *actual* thinking process. Interfering with that for the sake of uniformity or whatever is a genuine mistake (and yet so common!). I mean, should an editor reject a great novel simply because the manuscript isn't formatted to his liking? Of course not.

Maybe you can explain how a particular style actually models their thinking process, because I'm not sure how that would do it any better than a different style, or better than the pseudo code you have to hand in with your homework. I realize I'm going to a lowly community college, but pseudo code was a part of the rubric for each of my assignments; I would hope this isn't rare.

And the publishing industry was definitely a bad example for your point. Writer's Digest made it a point to discuss manuscript format while I was subscribed, and they're apparently still at it.

When you are attempting to impress a magazine editor, professionalism counts. If you are a beginning writer without a strong industry reputation, you can''t afford to submit material in a manner that marks you as a novice or an amateur.

full article

Publishers are all too happy to send a rejection letter in response to anything that they cannot read.