Re: enforcing coding style

Re: enforcing coding style

I'm glad that we have e-mail list and not fax lists otherwise I would feel
responsible for the death of a rain forest.  It's good to see this action on
sweng-gamedev.

For me the coding style is something more than pretty code.  Consider the
following:

"Keeping a culture alive as a team grows is a huge challenge"..."Sloppiness
is not tolerated." -Mark Lucovsky on the "culture" that was essential for
the development of WinNT.

A style standard is one way of creating (um... forcing?) a culture.
Functionally, a standard coding style will not make your code faster or
elegant.  But there might be another purpose.

The army enforces a "culture" by requiring cadets to make their bed every
day- with no wrinkles.  This doesn't make them better marksmen.  It does
create a culture of disipline.  In the coding example, enforcing a standard
is a way of stating "sloppyness will NOT be tollerated".

Creating a script to do this creates a less defensive posture with
developers than ruling with an iron fist and golden style sheet.

So in the interest of saving some bandwidth:
1.  I know...this isn't the Army
2.  Forcing people to do things may create a hostile "culture"
3.  WinNT isn't perfect
4.  I'm not saying this is right, it's merely a consideration(one that I
think might not have a practical implementaiton)
5.  The idea of a fax-list is pretty stupid

Eric

_______________________________________________
Sweng-gamedev mailing list
Sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Re: enforcing coding style

On Sat, 1 Mar 2003 01:05:12 -0500 
Eric Preisz <epreisz <at> d-a-s.com> wrote:

> The army enforces a "culture" by requiring cadets to make their bed
> every day- with no wrinkles.  This doesn't make them better marksmen.
> It does create a culture of disipline.  In the coding example,
> enforcing a standard is a way of stating "sloppyness will NOT be
> tollerated".

Well regimented armies are neither known for the accuracy of their
analytical processes, or their creativity.  

Consider the old principle of the doing the least number of things
possible while still attaining the target.  Where do coding standards
fit in there?  Yes, cultures and group definitions are important, even
necessary, but are coding standards both a suitable lever _and_ the
smallest possible lever for that use?

--

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw <at> kanga.nu               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Sweng-gamedev mailing list
Sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Re: enforcing coding style

Javier Arevalo wrote:
>I strongly disagree that it's a bad idea. In my experience it has worked
>great. Also, people who refuse to follow such a basic part of the process
>will surely give trouble later on, so get rid of them today if you can
>afford it.

We have a very pragmatic view on it here. We only have senior
programmers, and as such, it is fair to assume they have settled
on a particular style (in regards to indenting, etc) years ago
and that trying to change people would be more hassle than it
is worth.

Interestingly, I (and others) actually find it incredibly useful
to *not* settle on one style. The benefit is that you can often
immediately see who wrote a piece of code based purely on what
the code layout looks like. For example, if the brackets are
on the same line as the if/for, I wrote it. If the brackets are
indented from the if/for, Phil wrote it. If there's a space
between the function name and the first parenthesis, Bob wrote
it. Etc.

The benefit here is that you know exactly who to go to when you
want to ask about that code X does, or when code Y has a bug that
you don't have time to fix right now. Saves a bunch of digging
around in SourceSafe until you find the version when that
particular code was introduced.

Besides, how the code is indented is incredibly irrelevant in
comparison to e.g. how well it is commented. In fact, if someone
claims that a piece of code isn't readable because of its
indentation, I'd say you have a more serious problem with lack
of commenting.

Christer Ericson
Sony Computer Entertainment, Santa Monica

_______________________________________________
Sweng-gamedev mailing list
Sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Re: enforcing coding style

I used to hate TAB's.

However they are not so bad so long as

A) Your indentation amount is equal to the tab setting
B) tabs are only used for indentation, or for lining up comments on the
right

YMMV of course.

It is evident from all the "as God indented" posts that it will be very
difficult to get everyone on the project to agree to an
indentation/bracketing/naming/underscore/tabbing convention.  Does not mean
you can't try though.

Sean

----- Original Message -----
From: <phil_wilkins <at> playstation.sony.com>
To: <sweng-gamedev <at> midnightryder.com>
Sent: Friday, February 28, 2003 10:58 AM
Subject: RE: [Sweng-gamedev] enforcing coding style

>
> > Enforcing coding style is quite an arduoustask when forcing coders to
> conform to a style doc.
>
> So don't do it.
>
> Seriously, it's not worth the hassle.
>
> I mean, precisely what do you have to gain by making sure everyone formats
> their brackets the same way you do?
>
> Now how much work will it take, and how much resentment will it generate
> from programmers who don't conform to your particular style?
>
> Cheers,
> Phil
>
> PS Brackets on their own lines, in line with the body, indented from the
> parent. As God intended.

_______________________________________________
Sweng-gamedev mailing list
Sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Code comments

On Sat, 01 Mar 2003 00:36:01 -0800
christer_ericson <at> playstation.sony.com wrote:

> Besides, how the code is indented is incredibly irrelevant in
> comparison to e.g. how well it is commented. In fact, if someone
> claims that a piece of code isn't readable because of its
> indentation, I'd say you have a more serious problem with lack
> of commenting.

Ugh. I don't agree at all. I used to be really big on comments but I
have totally changed my mind in the last few years.

Comments don't go well with refactoring code. It's yet another thing
to update (which adds to the tendency not to refactor code), or it's
left out of date, at which point it's even worse than no comments.

My personal preference today is:
- Functions so simple that it's *obvious* what they do. The name of the
function should be enough of a comment. Ideally I like my functions to
be < 10-15 lines of code (that's totally arbitrary and a very rough
measurement intended to explain what I mean by short).

- Classes should be small and with a single objective. Just seeing the
class name and glancing at the public member functions should be enough
to use it.

- Use unit tests. Even better if developed test-first. That's the best
type of comment you'll ever have: it's impossible not to have it up to
date, and it shows you the details of how to use something exactly.

- Comments should be limited to weird, obscure code optimizations (and
use those only when absolutely necessary, of course).

- I also sometimes like to have high-level documentation for a library
or module.  That usually involves writing very short comments on the
interface classes and functions and running Doxygen.

But as a whole, I really don't like using comments anymore. Whenever I
feel the urge to add a comment, I instead make my code clearer, or
create a new function. 

--Noel
llopis <at> comcast.net

_______________________________________________
Sweng-gamedev mailing list
Sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Re: enforcing coding style

No, March first is not the official pick-on-Christer day. But I had to
reply to this also.

On Sat, 01 Mar 2003 00:36:01 -0800
christer_ericson <at> playstation.sony.com wrote:

> We only have senior programmers

I find it interesting that you only have senior people. Are you actually
writing games, or are you in some technology group? I find that to do a
full game, having a mix of senior and junior programmers is pretty
useful. Junior programmers can work on things that would be boring to
more experienced programmers that have done fifty times already, while
at the same time learning the ropes.

> We only have senior programmers, and as such, it is fair to assume
> they have settled on a particular style (in regards to indenting, etc)
>  years ago and that trying to change people would be more hassle than
> it is worth.

That sounds a bit scary. That sounds like they have their minds made up
and don't want to learn anything else. My view is that if changing
something they are *used* to is a hassle, then they don't belong in the
team. I don't care how talented or senior they are.  A team with only a
few senior programmers and several junior programmers, all with open
minds and willing to learn, will be much more effective in the long run.

--Noel
llopis <at> comcast.net

_______________________________________________
Sweng-gamedev mailing list
Sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

GDC roundtable on software engineering

While we're at it, I wanted to remind people that next week I'll be
running a roundtable at GDC about software engineering in the game
industry:  By the Books: Solid Software Engineering for Games.

The same roundtable will be held three times: 
- Thursday,  10:15-11:15AM
- Friday, 10:30-11:30AM
- Saturday, 9:00-10:00AM

The notes from last year's roundtable are available at: http://www.convexhull.com/sweng/GDC2002.html

Drop by if you get a chance. Last year it was definitely a fun and
rewarding experience to meet so many people who were actually interested
in software engineering. 

See you all next week (or at least, those of you going to GDC).

--Noel
llopis <at> comcast.net

_______________________________________________
Sweng-gamedev mailing list
Sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

RE: enforcing coding style

Sean Palmer wrote:
> It is evident from all the "as God indented" posts that it will be very
> difficult to get everyone on the project to agree to an
> indentation/bracketing/naming/underscore/tabbing convention.
> Does not mean
> you can't try though.

My own take on the indentation war is:  Don't fight the development
environment.  In our shop, everyone uses Visual Studio.  I, at least, will
hit ctrl-A, alt-F8 to autoformat several times in the course of any file I'm
writing.  I do it pretty much any time I cut and paste or any time I
otherwise add or remove levels of scope.

If someone else has carefully indented their brackets, tabbed in their
initialization lists, or so forth, then that's all going to get undone and
it's going to become a real headache to figure out what functional code I've
changed by diffing the source control versions.

So why fight it?  I don't like all of Visual Studio's autoformatting rules,
but I like them a lot better than spending the time to line everything up
myself and banning the use of autoformat throughout the company.  In a shop
with multiple development environments, I suppose there's a more compelling
case to be made against it.  As usual, YMMV.

Regards,
Kyle

_______________________________________________
Sweng-gamedev mailing list
Sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Re: enforcing coding style

----- Original Message -----
From: "Sean L. Palmer" <seanpalmer <at> directvinternet.com>
To: <sweng-gamedev <at> midnightryder.com>
Sent: Saturday, March 01, 2003 11:41 AM
Subject: Re: [Sweng-gamedev] enforcing coding style

> I used to hate TAB's.
>
> However they are not so bad so long as
>
> A) Your indentation amount is equal to the tab setting
> B) tabs are only used for indentation, or for lining up comments on the
> right

TABs should be only used to indent code blocks. One tab = one indentation
level. Then you configure your tab size to whatever you like most (2, 3, 4,
8 characters). Any other use (to align stuff on the right and such) is
guaranteed to display wrong on different editors / settings /
interpretations of the tabs: for everything else, I use plain spaces.
Using this standard, everybody will display the code as he likes, and there
is no way to screw up (unless someone is disabling TABs thus mixmatching
with spaces, which is the worst thing you can do to a document). Of course,
YMMV.

Giovanni Bajo

_______________________________________________
Sweng-gamedev mailing list
Sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com