[vlc-devel] commit: Port panoramix to X RandR with XCB (incomplete) ( Rémi Denis-Courmont )

[Rémi Denis-Courmont]

Le mercredi 10 juin 2009 22:45:17 Laurent Aimar, vous avez écrit :
>  Please respect the coding style of the file you edit (including var
> prefixes), it's a real mess otherwise, otherwise revert if you don't want
> to fix it.

The fact that spacing is normal rather correct is accidental. But it's bound 
to occur every so often for as long as VLC retains its unusual and confusing 
spacing convention, which probably means as long as I continue to write VLC 
code.

As for Hungarian notation, I really think it's more harmful than good. If 
someone wants to fix it, I don't care, but I won't waste my time on this. 
'pf_' is used for both float pointers and function pointers which is worse 
than having no prefixes. 'i' is used for all integers types, even though the 
only likely unnoticed integer types errors are width and signedness 
mismatches. 'f_' has the same problem to a lesser extent with float and 
double. Also, I see an anti-pattern in using int indiscriminately just to 
match 'i_'. 'p_' is used for almost all pointer types. Since the compiler will 
whine loudly if you even mix pointers with integers or floats, it's really 
only making lines longer -> that's probably the most annoying part. I know 
only one other large user of Hungarian notation, the Win32 API uses it much 
more sensibly than VLC. And while you got that I don't like Hungarian notation 
at this point, I need to add that VLC is not even following its true concept. 
For the reference, see 
http://blogs.msdn.com/ericlippert/archive/2003/09/12/52989.aspx

Keeping existing structures internally consistent, sure. But cosmeticizing new 
functions... I think there are more pressing/thrilling tasks.

Anyway, I really feel like the VLC conventions were set just for the ******* 
sake of being different from everything else. Hence annoying as possible, 
really.

And there I lost another thirty minutes into writing a pointless email.

-- 
Rémi Denis-Courmont
http://www.remlab.net/