Re: Coding Style

[george anzinger]

Anton Altaparmakov wrote:

> At 06:29 20/01/2001, Linus Torvalds wrote:
> 
>> On Fri, 19 Jan 2001, Mark I Manning IV wrote:
> 
> [snip]
> 
>>  > > And two spaces is not enough. If you write code that needs 
>> comments at
>>  > > the end of a line, your code is crap.
>>  >
>>  > Might i ask you to qualify that statement ?
>> 
>> Ok. I'll qualify it. Add a "unless you write in assembly language" to the
>> end. I have to admit that most assembly languages are terse and hard to
>> read enough that you often want to comment at the end. In assembly you
>> just don't tend to have enough flexibility to make the code readable, so
>> you must live with unreadable code that is commented.
> 
> 
> Would you not also add "unless you are defining structure definitions 
> and want to explain what each of the struct members means"?
> 
> [snip]
> 
>> Notice? Not AFTER the statements.
>> 
>> Why? Because you are likely to want to change the statements. You don't
>> want to keep moving the comments around to line them up. And trying to
>> have a multi-line comment with code is just HORRIBLE:
> 
> 
> And structs are not likely to change so this argument would not longer 
> apply?
> 
> Just curious.

I am curious about another style issue.  In particular _inline_ in ".h" 
files.  The "style" for this as practiced today is about to run into a 
brick wall.  Try, for example, referring to "current->need_resched" 
within the spin_lock() macro.  I don't think you can get this to work 
with the current kernel, and if you can, a) let me know how, and b) it 
is much too hard.  Imho it is time to rethink how (or where) we put 
_inline_ code.

I think the problem could be fixed by a convention in the compiler that 
says something like "_inline_" code will be compiled when a reference to 
it is encountered, but this is outside the standard (i.e. the standard 
allows it to be as it is and does not disallow my proposed convention, 
as I understand the standard).

George