Re: Coding standards

[David Laight]

> I found a couple that used ~4space indent, and used tabs too (they 
> seemed to expect 1tab = 8, as the code looked neat in a standard text 
> editor).

Probably vi with autoindent, tabstop=8 and shiftwidth=4 (my preferred indent).

More fun can be had arguing over whether to do:

if (...) {
    	...
    } else {
    	...
    }
or:
    if (...)
    {
    	...
    }
    else
    {
    	...
    }
or:
    if (...)
    	{
    	...
    	}
    else
    	{
    	...
    	}

If you have a paper listing you definitely need '} else {' on
a single line.  Otherwise you lose track of the control flow
when reading it.
(Never mind that you get many more lines on a page/screen.)

Of course the opening '{' for a function MUST be in column 1.

A coding standard really ought to discuss namespace usage and
pollution.  Any reasonable layout is usually ok.
(OTOH I much prefer that tab stops be at 8 character intervals.)

David

Coding standards

[Robert North]

David Laight david-at-l8s.co.uk |Wine Mailing Lists| wrote:
> A coding standard really ought to discuss namespace usage and
> pollution.  Any reasonable layout is usually ok.
> (OTOH I much prefer that tab stops be at 8 character intervals.)

Name space polloution, now there's something I should have thought of 
myself <Kicking myself hard>.

It's been bugging me for quite a while, as I've had problems serious 
with namespace polloution in SQL, and C++.
(It really annoys me when C++ has it's namespace polluted, because 
nobody uses the namespace builtin, or the namespace feature is broken in 
a compiler)

So, What do people want to do to protect their namespaces ??
        -Rob.

Coding standards

[Dimitrie O. Paun]

On November 26, 2002 01:19 pm, Robert North wrote:
> So, What do people want to do to protect their namespaces ??

This is not a big problem for Wine. In Wine, namespaces are
per DLL, and those are defined by MS anyway.

Inside a DLL, keep related things in a file, and mark all that
you can static. If you do that, 99% of non-static functions map
1-to-1 to an exported DLL function, so you are OK.

Anyway you do it, I seems to me you have to try real hard to 
mess up the namespace in a single DLL. :)

Coding standards

[Robert North]

Dimitrie O. Paun dpaun-at-rogers.com |Wine Mailing Lists| wrote:
> On November 26, 2002 01:19 pm, Robert North wrote:
> > So, What do people want to do to protect their namespaces ??
>
> This is not a big problem for Wine. In Wine, namespaces are
> per DLL, and those are defined by MS anyway.
>
> Inside a DLL, keep related things in a file, and mark all that
> you can static. If you do that, 99% of non-static functions map
> 1-to-1 to an exported DLL function, so you are OK.
>
> Anyway you do it, I seems to me you have to try real hard to 
> mess up the namespace in a single DLL. :)

While the above is true, you can still pollute your own namespace.
And to this end there's this section in the "DEVELOPERS-HINTS" file:
"NAMING CONVENTIONS FOR NON-API FUNCTIONS AND TYPES"

Always pays to read the doccumentation ;-)
    -Rob.

Coding standards

[Fabian Cenedese]

> > I found a couple that used ~4space indent, and used tabs too (they
> > seemed to expect 1tab = 8, as the code looked neat in a standard text
> > editor).
>
> Probably vi with autoindent, tabstop=8 and shiftwidth=4 (my preferred indent).

Of course everyone has his own taste and there's nothing wrong with 8. We
just found that with 8 spaces there's very much indentation if you have quite
some nested ifs/whiles/fors/whatevers. While still trying to stay under 80 
chars
per line (for a nice printing) you don't have much space left to put code on :)

bye  Fabi

Coding standards

[David Laight]

> > Probably vi with autoindent, tabstop=8 and shiftwidth=4 (my preferred indent).
>
> Of course everyone has his own taste and there's nothing wrong with 8. We
> just found that with 8 spaces there's very much indentation if you have quite
> some nested ifs/whiles/fors/whatevers. While still trying to stay under 80 
> chars per line (for a nice printing) you don't have much space left
> to put code on :)

Indeed - printing in one reason you should not set the tab size to
anything other than 8.

With vi and sw=4,ts=8,ai you indent with ^T and outdent with ^D.
vi adds the correct number of tabs and spaces to end up in the
right position.

8 char indents (as used by netbsd) to tend to leave you trying to
pretify code in about 16 colums sometimes.
Made more likely if your style involves 2 indents for a switch
statement, eg:
    switch (...) {
    	case ...:
    		break;

David

Coding standards

[Sylvain Petreolle]

is code printing a really common thing for you ?
> Indeed - printing in one reason you should not set the tab size to
> anything other than 8.

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Coding standards

[David Laight]

On Wed, Nov 27, 2002 at 01:44:49PM +0100, Sylvain Petreolle wrote:
> is code printing a really common thing for you ?

Not these days, I guess it went out of fashion with screen
editors and terminal with >24 lines.
Also with source files that are larger than a single tree :-)
Actually big source listing only really work on fan-fold paper,
piles of A4 sheets are not the same.
In the old days we printed the source and generated code for
the project - was just over a box of paper (2500 sheets fan-fold).

Since it is actually quite common to use tab to line up things
that are not at the start of a line (eg structure definitions),
you can only look at a file with tabs set to the same column
positions as when it was written.  So 8 columns tabs are good...

(OTOH I have tried to look at unix source files under M$, gave in
and installed netbsd.)

David

Coding standards

[Zsolt Rizsanyi]

On Wednesday 27 November 2002 08:54, Fabian Cenedese wrote:
> > > I found a couple that used ~4space indent, and used tabs too (they
> > > seemed to expect 1tab = 8, as the code looked neat in a standard text
> > > editor).
> >
> > Probably vi with autoindent, tabstop=8 and shiftwidth=4 (my preferred
> > indent).
>
> Of course everyone has his own taste and there's nothing wrong with 8. We
> just found that with 8 spaces there's very much indentation if you have
> quite some nested ifs/whiles/fors/whatevers. While still trying to stay
> under 80 chars
> per line (for a nice printing) you don't have much space left to put code
> on :)

You seem to not understand :)
tabstop=8:shiftwidth=4 means that the tabs are 8 chars wide, but the 
indentation is 4 chars wide.
That means that when you indent once 4 chars is used for indentation, if you 
indent twice then a tab (8 chars) is used. If you indent one more then one 
tab and 4 chars are used (that is 12 chars).
Vim automatically manages indentation or you can indent/unindent manually.
So the indentation is 4, but tab means 8. And that is much better for printing 
than use tabs with same strange width, because printers do not understand 
that. :)

Regards
Zsolt