Xorg coding style (Was: Re: Radeon TV-in support in Xorg CVS.)

[Ronny V. Vindenes]

søn, 03,.10.2004 kl. 10.49 -0400, skrev Vladimir Dergachev:
> >>       overlay windows)
> >>
> >
> > There are a couple of compile failures with gcc 3.4.2:
> > radeon_video.c:2112: error: label at end of compound statement
> > fi1236.c fails to compile because of missing prototype for
> > MT2032_dump_status().
> >
> > Please apply attached (trivial) patch.
> 
> Fixed. Thank you !
> 
> >
> > Also I have to say the sources in drivers/i2c are virtually unreadable -
> > parts are without ANY indentation and whitespace while the rest is not
> > using any consistent indentation or whitespace scheme. Please fix this
> > while the code is still fresh.
> 
> No identation ? I guess I've been looking so long at these that I can't 
> tell. The only thing that I see is that fi1236.c has two different 
> identation styles - XFree86 and my own, I'll fix that when I get a chance.
> 

The following functions have no or partial indentation:

fi1236.c:
MT2032_dump_parameters, MT2032_getid, MT2032_shutdown, MT2032_init,
MT2032_no_spur_in_band, MT2032_calculate_register_settings,
MT2032_wait_for_lock, MT2032_implement_settings, MT2032_optimize_VCO,
FI1236_get_afc_hint, MT2032_get_afc_hint, TUNER_get_afc_hint,
MT2032_dump_status, MT2032_tune, FI1236_set_tuner_type,
fi1236_dump_status

msp3430.c:
MSP3430DumpStatus, InitMSP34x5D

tda9850.c:
tda9850_mute, tda9850_sap_mute, tda9850_getstatus, 

tda9885.c:
tda9885_getstatus, tda9885_setparameters, tda9885_dumpstatus


> PS On second thought, are you using Emacs ? Set your tabs to 8 spaces - 
> this is what my editor (Nedit) uses.
> 

I noticed it using vi and less. I suspect your editor is doing some
automagic to hide the ugliness from you. (I checked with hexdump - there
are no '\t's, it's strictly "one line\nthe next line")

Most of the files I'm familiar with(*) in xorg, uses spaces for
indentation, but some also use tabs - could we please have an official
stance on this? Personally I prefer real spaces, but a strict policy
either way is infinitely better than the current mix. I understand the
reluctance to run the whole code base through indent or similar tools,
but could we at least state some policy for new code?

(*) Admittedly not all that many.

-- 
Ronny V. Vindenes <s864 at ii.uib.no>