"cr88192" <cr88192@[EMAIL PROTECTED]
> writes:
> "Richard Heathfield" <rjh@[EMAIL PROTECTED]
> wrote in message
> news:HMudnfqSToSaMb_VnZ2dneKdnZydnZ2d@[EMAIL PROTECTED]
>> cr88192 said:
>>
>> <snip>
>>>
>>> now, I usually code in notepad,
>>
>> Oh dear. :-)
>>
>
> all in all it is a good and simple editor...
>
>
>>> which has inflexible 8-space tabs, so
>>> usually I use this.
>>> if the tab space is adjustable, usually I like 4 space tabs.
>>
>> Tab/space wars are so 1990s, though, aren't they?
>>
>
> yeah...
> anymore, it is mostly forgotten, but I still usually use 4 or 8...
>
>
>>> 2 or 3 spaces is IMO too little.
>>
>> And IMO 3 is too many. Vive la difference!
>>
>
> yeah, it is a matter of taste I guess. 2 or 3 spaces IMO is painful to
read
> or skim...
>
>>> 1 space is just horrid (may as well not indent at all...).
>>
>> Agreed.
>>
>>> usually, I put opening and closing braces on their own lines, and
closing
>>> braces are indended the same as the opening braces.
>>
>> Agreed again.
>>
>> You forgot <stdio.h>
>>
>
> yeah, I inferred this, since my point was more about demonstrating style
> than actually working code.
>
>>> int main(int argc, char *argv[])
>>> {
>>> FILE *fd;
>>> if(argv<2)
>>
>> You meant argc.
>>
>
> yes, typing does not always work perfectly...
>
>
>>> {
>>> printf("usage: %s <filename>\n", argv[0]);
>>
>> If argc is 0, the behaviour is undefined. If it is >= 1, argv[0] must
>> represent the program name in some way, but need not be a string
>> representing the invocation name for the program. It could even be a
pid!
>>
>
> this is a common practice though, and also I don't personally know of
any OS
> where argc is not at least 1...
>
>
>>> return(-1);
>>
>> This has no ****table meaning (and the parentheses are redundantly
>> superfluous).
>>
>
> return(-1);
> is the same as:
> return -1;
>
> only, the parens are a matter of style and tradition...
>
>>> }
>>>
>>> fd=fopen(argv[1], "rb");
>>> ...
>>> return(0);
>>
>> Again, the parentheses are superfluously redundant.
>>
>>> }
>>>
>>> note that EXIT_SUCCESS and EXIT_FAILURE are considered "more correct"
for
>>> main return values,
>>
>> 0 is fine - it means success.
>>
>
> yeah.
>
>>> but 0 and -1 are more common/traditional.
>>
>> A -1 return value has no de jure meaning in C (which is, at least, in
>> keeping with the better kinds of tradition - if we knew why we did
them,
>> they wouldn't be traditions!).
>>
>> To indicate failure ****tably, use EXIT_FAILURE.
>>
>
> it is more correct, but -1 is a very common value for indicating error
as
> well.
> I think usually any value other than 0 counts as an error.
>
>
>>> IMO, both forms:
>>> if(...)
>>> {
>>>
>>> and:
>>> if(...) {
>>>
>>> are fairly common and acceptable, but most people put the brace on its
>>> own line for functions, and rarely for structs or unions.
>>
>> The word "most" is arguable. K&R's style is perniciously persistent
even
>> now. And a significant number of Allman adherents /do/ put a struct
brace
>> on its own line.
>>
>
> I comment based on what I have most often seen, but these conventions
are by
> no means universal.
>
>
>>> it is common for commas to be followed by a space ("f(x, y);" but not
>>> "f(x,y);").
>>
>> True, and wise.
>>
>>> some people precede/follow parens and/or operators with spaces.
>>
>> True, and a matter of taste, I think. My own taste is for parentheses
not
>> to "command" any whitespace, but for binary operators to be separated
from
>> their operands by a space.
>>
>
> yeah, my case I don't usually use a space either (since to me the paren
is
> 'strong', and putting a space there makes it seem 'weak'...).
>
> my case, whether or not I use spaces around operators is a matter of
> situation, where usually they are used for breaking up expressions into
> recognizable parts, and sometimes for aligning groups of regularized
> expressions.
>
> sometimes terms for polynomial expressions can be broken up like this as
> well.
>
> 4*a*c - 2*b
>
>
>>> if certain single-letter variable names are used (especially,
>>> i,j,k,s,t,...) it is almost obligatory that they be certain types
(i,j,k
>>> are int, s,t are 'char *', ...).
>>
>> No, not really. Common, yes. Obligatory? Hardly.
>>
>
> sufficiently common patterns are almost obligatory.
> if one is going to use different types, they are better off avoiding
these
> names, for sake of reducing possible confusion.
>
>
>>>
>>> return is often/usually written as if it were a function call (common
in
>>> C, rare in C++).
>>
>> return /isn't/ a function call, and it seems to me from perusing this
>> group
>> and from what I've seen of good C code (in well-regarded literature, in
>> workplaces, and on the Web) that few if any experienced C programmers
>> treat it like one.
>>
>
> well, as noted, it is a lot more common in C IME, but it is almost never
> done in C++.
>
> however, I have personally seen a lot more code with the parens than
without
> the parens...
I agree with people who write real apps accessed by many peoples. And
these are:
It is clear and it works.
http://www.linuxjournal.com/article/5780
|
