[Geany-devel] On coding style

[Thomas Martitz]

On 08.09.2009 00:18, Enrico Tröger wrote:
> On Mon, 07 Sep 2009 00:43:02 +0200, Thomas wrote:
>
>    
>> Thomas Martitz schrieb:
>>      
>>> Lex Trotman schrieb:
>>>        
>>>> Several of the things you changed I had thought I had right, so
>>>> maybe hacking.html needs to be more explicit rather than just "like
>>>> the rest of the code".
>>>>
>>>>          
>>> This is what I had an argument with Enrico too recently. HACKING is
>>> nowhere near accurate, as it's poorly describing what style Enrico
>>>        
>
> As already said, I try to update the HACKING file soon. Still, in the
> argument we had recently, I told you that some of the issues I had with
> your coding style we had already discussed in the past (e.g. in the
> snippets patches). But you are right, if the style guidelines would be
> better and more detailed described, we could have saved this conversion
> (and maybe even this one).
> It's somewhat my bad, no doubt.
>
>
>    
>>> In addition, seem Enrico and Nick run with extra CFLAGS which reveal
>>> extra warnings (some of which warn for perfectly conform C code, but
>>> well ;) ) which are not documented.
>>>        
>
> They are not "documented" because these flags are not required not
> suggested or anything. *We* do use them because *we* do like to.
> Anyway, I posted the flags I use more than one time on the list (not
> sure which one, maybe this one, maybe geany at uvena.de). Let's do it once
> more:
> http://nopaste.geany.org/p/fe14fca2
>    

I think suggesting and documenting them officially would be a good idea.

> What exactly are you referring to by saying "some of which warn for
> perfectly conform C code". In case you are talking about the famous
> "don't mix code and variable declarations" warning, we could argue
> again. You would say, this is valid C and I would say this is not valid
> C. And we are both right as long as we don't specifiy about which C
> standard we are talking. Luckily, the HACKING file states the we want
> to stay compatible with C90 and developers can check their code with
> gcc's -ansi flag.
> Anyway, I really don't see a problem with this. Such things can be
> easily fixed and I didn't intend to really make this a big thing. If I
> did anyway, I'm sorry.
>    


Alright, I admit I knew about that guideline (and I know it's only valid 
C in C99). I tried hard to avoid having variable declarations after 
code, but I apparently failed (I can't remember now where it happened). 
That was my fault then.

>
> See above, such easy-to-fix compiler warnings are not a topic. I guess
> you are referring to the warning I was talking about in your patch when
> we discussed it on IRC, this was somewhat special because you modified
> a part of the code which was completely unrelated to your patch and
> this modification caused the warning. I just don't like doing many
> different, unrelated things in one patch.
> IMO patches should be rather atomic, similar to commits. But really,
> this is another story.
>
>    



It's not a problem at all. I'm perfectly fine for me if the coding style 
of geany is to avoid such shadow declarations, and I'll try to adhere to 
it. My point was, though, that if it was documented (maybe including the 
gcc option, since not everyone knows the bazillions of gcc options), it 
wouldn't have been a point of discussion in the first place :)

And yes, I know that part of the patch which introduced it was bad, I'm 
sorry for this. I would've taken it out in a new version, but then it 
was too late :)

Best regards.
>    
>> declarations or indentation when breaking long lines and stuff.
>> HACKING should be as explicit as possible, to avoid additional work
>> for *both*, the contributors and the reviewers.
>>      
>
> I fully agree and will try to improve this soon. Sorry for the
> inconvenience you experienced in the meantime.
>
>    

Awesome. I'm sorry for the same reason.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20090908/81dab0c2/attachment.html>