>>
>>> Sorry about those tabs. And my tab is 4 characters. BTW, I don't see how
>>> "80 chars per line" and "8-char tab" can get together. Seems
>>> contradicting to me...
>>
>>
>> You can have around 9 levels of indentation with these parameters, which
>> is still many more than any sane function would use.
>
>
> Yes, but at that level of indentation you would have 8 chars left. That's
not really an argument, is it? If you have 4 level of indentation (which is
quite reasonable), 8-char tabs waste 16 chars for nothing. Thats one fifth
or 20% of the maximum space allowed per line. 20% wasted.
No, it doesn't waste chars for nothing. Actually, it helps the readability
of the code by a whole lot...
If you need more than 4 level of indentation probably something is wrong
with your code. It is my personal opinion but I believe it is shared by
many others.
>
>>>
>>> That's not in the CStyle guide. And I prefer my style.
>>
>>
>> Perhaps it can be added there. But I don't think this is a matter of
>> style. It's just that the brackets are not necessary in this case.
>
>
> If it's not in the official CStyle guide, how am I supposed to follow
rules? Jiri complained about me not following them, but how can I know?
>
>
>>
>>>>
>>>> /* Encoding and writing first logical partition */
>>>> if (l != &(label->parts->list.head)) {
>>>>
>>>> had you used list_first()/list_next() you could check for l != NULL.
>>>
>>>
>>> Explained before.
>>
>>
>> We also have some other code which does this, especially in the kernel.
>> I guess you can change it to be more readable as Jiri suggested or just
>> leave it as it is.
>
>
> I can change it, and probably will. It's just I didn't notice those
functions before. But thanks.
>
>
>>>
>>> CStyle guide reference?
>>
>>
>> The majority of the rest of the code does that. It's usually better to
>> write code which follows the same, possibly implied, conventions. It's
>> also not clear to me whether not having the empty line there would not
>> result in Doxygen inappropriately joining the \brief and \description.
>
>
> Well, as I pointed earlier (in another thread about me not following
CStyle guide), there are places that break those rules already in mainline.
You noted how some libraries still use "lib" in their file names, how there
are USB error codes in errno.h and some deviations from license formatting.
>
> Don't take me wrong, but you can't expect me to follow rules, that are
not written (please don't try to apply this statement to outside world).
Would it be too much trouble to admit your rules are not complete and fix
them and then politely asking me/other devs to correct the code to apply to
the new rules, instead of arguing about it?
>
> The alternative is to accept some slight and reasonable deviations from
your preferred style. I would prefer this route than the other, because it
just is more "humane".
>
>
>>
>>
>> You may have noticed that this very long e-mail (except for the
>> technical discussion at its end) is primarily about nitpicking your
>> deviations from the cstyle or from the style of the other code. I think
>> the cause which provokes an e-mail like this is rooted in contributors'
>> tendencies to make deliberate exceptions from various rules. It is easy
>> to say: "I don't like this and I'll do it my way, using my preferred
>> style." But it won't work in a multi-developer project like HelenOS. If
>> the contributors merely tried to comply as much as possible with the
>> rules, both written and implied, we could save ourselves some time. We
>> are being quite pedantic about it because it is clear that if the code
>> gets merged with cstyle issues, somebody will have to eventually fix
>> them and you can guess who that somebody will be. The other alternative
>> is that we end-up with as many cstyles as there are contributors, that
>> is: a complete chaos. If you think we are a sort of cstyle nazis, I
>> recommend you undergo a code inspection session or two in eg. Solaris
>> sustaining organization where exceptions from the cstyle are not
>> permitted at all.
>
>
> 1) Why would you think I consider you CStyle nazis?
> 2) I think I try to fix my code to your liking. You may notice that I'm
just asking for other opinions on uncertain issues.
> 3) I'm not adding code to kernel or any other part (except for
checksum.{c,h}) - I'm creating my own code from scratch. That lessens the
issues to a certain degree.
> 4) If you consider only extreme ways and your way, the discussion is not
worth it. I never said noone should ever follow any rules.
>
>
> Dominik
>
>
> _______________________________________________
> HelenOS-devel mailing list
> [email protected]
> http://lists.modry.cz/listinfo/helenos-devel
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
