[Courses] Style (was Lesson Three: Basic Declarations & Expressions)

[Lorne Gutz]

Ohhhhh boy,   Sorry Jenn.  I didn't mean to ruffle and
feather here.

I did say preferable didn't I.    It should have been I
prefer.

Usually I don't give a dam about how people write code.
I like to see good algorithms and effective implimentation
of those algorithms.   Most of all though the code must
but readable by others.

The woman who taught me C ( some 14 years ago now) would
shutter at some of the code I see today.  She stressed strict
rules and self discipline.  Something that I took to heart and halved
the number of hours I spend debugging in the process.  So now
you'll know where I'm coming from when I don't take for granted.
 

C the language, allows more freedom that any other language I
know of.  You can do anything you wish even if its totally wrong.

cheers
Lorne

On Friday 11 October 2002 16:44, Jenn Vesperman wrote:
> On Sat, 2002-10-12 at 01:00, Eugene Teo wrote:
> > <quote who="Lorne Gutz">
> > u> IMO the  'int   main( void )' is preferable and by the way
> > u> main can have as many as 3 parameters.
> >
> > In short, personal preference. It is important to adopt a personal
> > style in developing applications.
>
> Disclaimer: The following is my opinion, and nothing but my opinion.
> Give it the weight of 'I've been working in the field for a bit more
> than ten years now', but please don't treat it as 'the boss says'. I'm
> speaking here as the person, and as a long-experienced programmer.
>
>
>
> I _strongly_ discourage style pedanticism. Everyone who programs
> develops their own style that works for them.
>
> Everyone's mind works differently. Everyone's -sight- works differently.
> Someone with a touch of astigmatism may not be able to see the parallel
> lines in the style:
>
> main (foo)
> {
> 	if (bar)
> 	{
> 		baz
> 	}
> }
>
>
> That person may find that this works better for them:
>
> main (foo) {
> 	if (bar) {
> 		baz
> 	} //end if (bar)
> } // end main
>
>
> Short form, before I write a long essay on it: people develop their own
> styles for -reasons-. They may not be able to articulate their reasons.
> And in single-person or small team projects, the individual style
> doesn't matter. Ignore it.
>
> In a larger project - that's what programs like indent are for. Use
> them. Let people develop the code their own way, and use a prettifier
> before release.
>
>
>
> It's like monitors and screen colours. I worked with a person who
> absolutely had to use white text on black. I absolutely have to use
> black text on white. We both got horrendous headaches if we stared at
> the other person's monitor for too long.
> Did this make his good and mine bad? Or vice versa? Nope.
>
> One day when we were discussing it, another person chimed in and said
> the best colour for him was .. I forget, but it was something like light
> blue on dark grey.
>
>
> In short, I don't think a discussion on style is especially helpful if
> it's 'this style bad, that style good'.
> A discussion that says 'I use this style and I like it because of blah'
> is fine. That helps people figure out which style works for them.
>
> That said, many project leads try to enforce a 'project style'. In
> Dancer's and my experience, such leads usually haven't programmed a lot
> themselves. Our take is 'which is more important, to have your $80/hour
> programmer counting tabs, or to have him adding that new feature or
> tracking that bug?'
>
>
> Eh. You can tell that this is a hot button for me. I'll shut up now.
>
>
>
>
>
> Jenn V.

-- 
Lorne Gutz
Baseband Design Group
Supervisor H/W Support