[vlc-devel] code conventions : line width ?
Rémi Denis-Courmont
rdenis at simphalempin.com
Fri Sep 12 12:48:47 CEST 2008
On Fri, 12 Sep 2008 11:03:33 +0200, Laurent Aimar <fenrir at via.ecp.fr>
wrote:
>> 79 characters not counting the newline character (yes, some places do
>> not follow this).
> I tend to dislike it as nowdays screen are much wider. It prevents using
> variable with explicit names if you want to comply with it (otherwise you
> end up using only a few words per line ;).
Long lines are not readable. Regardless of the width of your screen. Why do
you think real book (and TeX) use such short lines?
In any case, I do use the console quite a log, and it still is 80 character
wide. Also, if you have both hands on the keyboard, scrolling a long line
is painful.
>> That being noted I really dislike some of the conventions (Our Hungarian
>> notation is sometimes harmful. The parenthesizing is insane for not
>> matching what about every else agrees on).
> I strongly disagree with you on both points.
You can disagree with factual truth if you like (I don't).
As regards the Hungarian notation, the use of psz for not only string
pointers, but also character arrays is confusing (Microsoft uses psz and sz
respectively). The use of (p)p_foobar and i_foobar in the same struct is a
confusing. block_t is a total disaster with p_buffer and i_buffer instead
of (p_)data and (i_)length - in buffer management, you move the data
pointer and the useful length, not the buffer pointer and the buffer size!
But my main objection to the systematic Hungarian notation is the i_
prefix. It is CLEAR from the VLC source code, that it is used for any type
of integers, effectively negating the whole benefit of Hungarian notation
(to avoid type mismatch errors). Worse, it has caused widespread use of
"int" instead of any more appropriate type (especially unsigned and
size_t). This has caused a bunch of bugs, some security related, and
remains a rampant problem to this day in the code base. i_ is also used in
case where it is totally pointless, e.g. file descriptors, which are
abstract descriptors before they are integers.
And parenthesizing. It is a simple fact that the outstanding majority of
projects puts the space (if any) outside, rather than inside. It is FACTUAL
TRUTH - it just is. There are even some languages that enforce (e.g. bash)
or try to enforce (C#, Java...) this. Using different conventions is hugely
annoying when you're writing code daytime, and are involved in other
personal projects.
People disagree on indentation, on when/where to put brackets, but *almost*
none else uses spaces inside parenthesis.
--
Rémi Denis-Courmont
More information about the vlc-devel
mailing list