The maintainer won't accept it if it doesn't follow what he considers "proper" 
coding style.

Style is not a collective decision at all. Someone has to make sure the code is 
kept clean, readable (and of course stable in first place).

Some parts of Kannel code date back to 1999, so I guess there was a lot of 
people involved that's no longer part of the project. That's probably the main 
reason behind those style differences. That's not reason to mess all the rest 
for sure.

Do you think that putting "if's" on the same line and removing brackets are 
really a "benefit"? I'm not! I don't see any problems with the code style Alex 
is enforcing, imho he does a pretty good job keeping the code readable and tidy.

Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org



On 04/07/2010, at 23:56, Nikos Balkanas wrote:

> [You should reply to me, Cc the list, so that it is obvious from the headers, 
> to whom it is addressed]
> 
> Then I gather, from your own words that style is a collective decision. But 
> if you notice from the rest of kannel's code style has changed several times 
> since the beginning. Maybe the time has come for another such change, if it 
> benefits the community.
> 
> Of course noone can commit whatever he wants to the list, it is up to the 
> maintainer whether to accept it or not. And it is up to the contributor, 
> based on those rules, whether he will submit it or not.
> 
> BR,
> Nikos
> ----- Original Message ----- From: "Milan P. Stanic" <m...@arvanta.net>
> To: <devel@kannel.org>
> Sent: Sunday, July 04, 2010 10:47 PM
> Subject: Re: Patch: test/drive_smpp.c
> 
> 
>> [ You shouldn't post replies to me. I'm subscribed to list ]
>> 
>> On Sun, 2010-07-04 at 13:22, Nikos Balkanas wrote:
>>> If styling rules are one man's decision, better be acceptable and to
>>> a degree flexible, or they will deter contributors from submitting
>>> work. Which contradicts open source philosophy.
>> 
>> Styling rules are seldom one man's decision in free/open source. It is
>> usually a consensus established during initial phase of the project and
>> often copied from other successful projects.
>> If everyone is allowed to add/insert personal style/preferences that
>> leads to big mess and such code is hard to follow.
>> 
>> Newcomers are expected to adopt to the established rules and style.
>> 
>> I would like to see kannel in git repository and during discussion
>> about switching to new VCS I had temptation to propose that but because
>> I don't contribute code to kannel I resisted. I remember last Alex's
>> message about matter and even started to write reply but after little
>> thinking I ceased because I didn't like to disturb him with one useless
>> mail.
>> 
>>> Granted  kannel is in better shape than most other software, but
>>> there is always room for improvement.
>> 
>> Yes. I agree with you.
>> And, I really appreciate your contribution to kannel.
>> 
>>> BR,
>>> Nikos
>>> ----- Original Message ----- From: "Milan P. Stanic"
>>> <m...@arvanta.net>
>>> To: <devel@kannel.org>
>>> Sent: Sunday, July 04, 2010 12:52 PM
>>> Subject: Re: Patch: test/drive_smpp.c
>>> 
>>> 
>>> >On Sun, 2010-07-04 at 00:58, Nikos Balkanas wrote:
>>> >>I am very sorry. My apologies for the missunderstanding. My
>>> >>impression is that identation means replacing tabs with spaces and
>>> >>aligning left text according to level. I see here that you are
>>> >>actually asking about source code reformatting and even for a code
>>> >>change. Some of the styling options that you ask, especially that
>>> >>"if" statement, are unreadable by several people, including me.
>>> >>Well, not exactly unreadable, but very difficult to read. And that
>>> >>is a problem in the case of the author who is called to support it.
>>> >>Who decided on this style anyway?
>>> >
>>> >In the free/open source software usually maintainers are those who set
>>> >the rules and style.
>>> >
>>> >[ And usually (as is the case in kannel) these rules and style are far
>>> > better than in commercial software ]
>> 
>> -- 
>> Kind regards,  Milan
> 
> 


Reply via email to