440,854 Members | 849 Online
Need help? Post your question and get tips & solutions from a community of 440,854 IT Pros & Developers. It's quick & easy.

# Coding style survey

 P: n/a Which do you think is best? 1. a) type* p; b) type *p; 2. a) return (var); b) return(var); c) return var; 3. a) return (ptr->var); b) return(ptr->var); c) return ptr->var; 4. a) return (foo(ptr->var)); b) return(foo(ptr->var)); c) return foo(ptr->var); 5. a) a = (b+c); b) a=(b+c); c) a = b+c; d) a=b+c; 6. a) type foo(type arg1, type arg2, ...) { declarations; code; return; } b) type foo(type arg1, type arg2, ...) { declarations; code; return; } c) type foo(type arg1, type arg2, ...) { declarations; code; return; } d) type foo(type arg1, type arg2, ...) { declarations; code; return; } e) type foo(type arg1, type arg2, ...) { declarations; code; return; } f) type foo(type arg1, type arg2, ...) { declarations; code; return; } Nov 14 '05 #1
63 Replies

 P: n/a In article , Papadopoulos Giannis wrote: Which do you think is best? 1. a) type* p; b) type *p; It depends on the situation. What is the important object: The pointer p, or the object pointed to *p ? Occasionally you will see things like char* *p; which means that p points to a char-pointer. 2. a) return (var); b) return(var); c) return var; c 3. a) return (ptr->var); b) return(ptr->var); c) return ptr->var; Same 4. a) return (foo(ptr->var)); b) return(foo(ptr->var)); c) return foo(ptr->var); Same, but it should be foo (ptr->var) 5. a) a = (b+c); b) a=(b+c); c) a = b+c; d) a=b+c; None of the above. a = b + c; 6. a) type foo(type arg1, type arg2, ...) { declarations; code; return; } b) type foo(type arg1, type arg2, ...) { declarations; code; return; } c) type foo(type arg1, type arg2, ...) { declarations; code; return; } d) type foo(type arg1, type arg2, ...) { declarations; code; return; } e) type foo(type arg1, type arg2, ...) { declarations; code; return; } f) type foo(type arg1, type arg2, ...) { declarations; code; return; } None of the above. (b) with an empty line before declarations. Nov 14 '05 #2

 P: n/a It's a matter of personal preference. If someone doesn't like the way you do it, let them write a "pretty printer" to reformat it. If the company you are working for has a standard for any of these, comply with their standard. It has nothing to do with the correctness of the code, but may have impact on how the code will be maintained in the future. Papadopoulos Giannis wrote: Which do you think is best? 1. a) type* p; b) type *p; 2. a) return (var); b) return(var); c) return var; 3. a) return (ptr->var); b) return(ptr->var); c) return ptr->var; 4. a) return (foo(ptr->var)); b) return(foo(ptr->var)); c) return foo(ptr->var); 5. a) a = (b+c); b) a=(b+c); c) a = b+c; d) a=b+c; 6. a) type foo(type arg1, type arg2, ...) { declarations; code; return; } b) type foo(type arg1, type arg2, ...) { declarations; code; return; } c) type foo(type arg1, type arg2, ...) { declarations; code; return; } d) type foo(type arg1, type arg2, ...) { declarations; code; return; } e) type foo(type arg1, type arg2, ...) { declarations; code; return; } f) type foo(type arg1, type arg2, ...) { declarations; code; return; } -- "It is impossible to make anything foolproof because fools are so ingenious" - A. Bloch Nov 14 '05 #3

 P: n/a Nick Landsberg wrote: It's a matter of personal preference. If someone doesn't like the way you do it, let them write a "pretty printer" to reformat it. If the company you are working for has a standard for any of these, comply with their standard. It has nothing to do with the correctness of the code, but may have impact on how the code will be maintained in the future. I know.. I have already my style (which is by the way a bit peculiar).. I just wanted to know how other c programmers code (either experts or novice)... Nov 14 '05 #4

 P: n/a "Papadopoulos Giannis" wrote in message Which do you think is best? 1. a) type* p; b) type *p; a) is clearer, since p is a type*. However b) is traditional, because of C's rules on building compound types. See function pointers for further details. 2. a) return (var); b) return(var); c) return var; c). return is not a function. 3. a) return (ptr->var); b) return(ptr->var); c) return ptr->var; c), return is not a function. 4. a) return (foo(ptr->var)); b) return(foo(ptr->var)); c) return foo(ptr->var); c), return is not a function. Though you want to ask why you are returning the return value from another function directly - this is unusual. 5. a) a = (b+c); b) a=(b+c); c) a = b+c; d) a=b+c; c). 6. a) type foo(type arg1, type arg2, ...) { declarations; code; return; } b) type foo(type arg1, type arg2, ...) { declarations; code; return; } c) type foo(type arg1, type arg2, ...) { declarations; code; return; } d) type foo(type arg1, type arg2, ...) { declarations; code; return; } e) type foo(type arg1, type arg2, ...) { declarations; code; return; } f) type foo(type arg1, type arg2, ...) { declarations; code; return; } c) or d). Curly braces should always be on a line of their own and should always align with the closing curly brace. A space between declarations and code is generally useful, but |I wouldn't insist on it. Nov 14 '05 #5

 P: n/a Malcolm wrote: "Papadopoulos Giannis" wrote in messageWhich do you think is best? {snip} <--- not curly braces :)6.a)type foo(type arg1, type arg2, ...) {declarations;code;return;}b)type foo(type arg1, type arg2, ...) {declarations;code;return;}c)type foo(type arg1, type arg2, ...){declarations;code;return;}d)type foo(type arg1, type arg2, ...){declarations;code;return;}e)type foo(type arg1, type arg2, ...) {declarations;code;return; }f)type foo(type arg1, type arg2, ...) {declarations;code;return; } c) or d). Curly braces should always be on a line of their own and should always align with the closing curly brace. A space between declarations and code is generally useful, but |I wouldn't insist on it. It's again only a matter of personal preference and has nothing to do with the correctness of the code or C, the language. Back in the stone age of computing I developed a {} style which put the curly braces on the same line as the "if, for, while, etc." statements so I could use *nix system utilities to check for flow of control, e.g. g/[{}]/p in the editor. Of course, this did not help all the time. It was just a crutch. If you are in an organization which has certain edicts for where braces go, and you don't like them, then write your own "pretty printer" and "un-pretty printer" to go back and forth from your preferred style to the organization's style. (Said pretty printer is a pretty good exercise in learning the c-language, too.) We've had "brace wars" in C for longer than I care to remember. -- "It is impossible to make anything foolproof because fools are so ingenious" - A. Bloch Nov 14 '05 #6

 P: n/a On Tue, 27 Jan 2004 00:15:20 +0200, Papadopoulos Giannis wrote in comp.lang.c: Which do you think is best? What I think is that people who ask about "style" issues are asking the wrong question. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html Nov 14 '05 #8

 P: n/a Malcolm wrote: .... snip ... c) or d). Curly braces should always be on a line of their own and should always align with the closing curly brace. A space between declarations and code is generally useful, but |I wouldn't insist on it. I would. And the only code oriented place I insist on a separate line for an opening brace is immediately after a function header. Otherwise it belongs on the end of a line. e.g. my style: int function foo(int bar) { /* declarations */ /* code after a blank line, unless no declarations */ if (bar) { /* barstuff. Indentation shows controlling clause */ } } /* foo */ /* I insist on labelling the end of a function */ -- Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! Nov 14 '05 #9

 P: n/a Papadopoulos Giannis wrote: Which do you think is best? 1. a) type* p; b) type *p; The latter. The former leads people to believe that int* p1,p2; declares two pointers to int, which it does not. 2. a) return (var); b) return(var); c) return var; The third, but this is purely a matter of taste - except that I think the second option makes it look too much like a function call. IOW, I'd write the third; wouldn't frown at the first; but would remark upon the second. 3. a) return (ptr->var); b) return(ptr->var); c) return ptr->var; 4. a) return (foo(ptr->var)); b) return(foo(ptr->var)); c) return foo(ptr->var); Ditto, and ditto. 5. a) a = (b+c); b) a=(b+c); c) a = b+c; d) a=b+c; C or D, depending on context. 6. a) type foo(type arg1, type arg2, ...) { declarations; code; return; } No. I'd use this layout, with the opening brace at the end of the line, for a block inside a function (for, if, etc.), but not for the function block itself. c) type foo(type arg1, type arg2, ...) { declarations; code; return; } d) type foo(type arg1, type arg2, ...) { declarations; code; return; } One of these; which I choose depends on the size of the function, but usually D. e) type foo(type arg1, type arg2, ...) { declarations; code; return; } *Grk* No. Never. It's weird. Richard Nov 14 '05 #10

 P: n/a "Malcolm" wrote: "Papadopoulos Giannis" wrote in message 4. a) return (foo(ptr->var)); b) return(foo(ptr->var)); c) return foo(ptr->var); c), return is not a function. Though you want to ask why you are returning the return value from another function directly - this is unusual. Not at all. The function containing the return statement could be a function which prepares the data for foo(). For example, take a deque, implemented as a doubly linked list. The DLL, of course, has a function called dll_delete(). The deque has two functions, deq_l_delete() and deq_r_delete(). deq_l_delete(q) finds the leftmost element of q, then passes it to dll_delete(); deq_r_delete(q) does the same at the other end. The last statement of deq_l_delete() could be return dll_delete(leftmost); Richard Nov 14 '05 #11

 P: n/a CBFalconer wrote in message news:<40***************@yahoo.com>... int function foo(int bar) { ... if (bar) { /* barstuff. Indentation shows controlling clause */ } } ... Bravo! Glad to see someone adhering to the TRUE STYLE. From an earlier discussion I thought comp.lang.c'ers thought it was passe. Which do you think is best? 1. a) type* p; b) type *p; (a) seems more logical, *except for one big problem*: type* p1, p2; won't mean what it looks like it should mean. Use (b) therefore unless you're looking for trouble. Someone else wrote return foo(bar); it is unusual to return another function's return value. Hunh? I do it all the time. Admittedly I soemtimes end up rewriting it, if only for debug purposes. James Nov 14 '05 #12

 P: n/a Papadopoulos Giannis wrote in message news:... Which do you think is best? [] a) return (var); b) return(var); c) return var; If it's an expression then i'll return it in brackets else i'll return the identifier. a) a = (b+c); b) a=(b+c); c) a = b+c; d) a=b+c; If you program in languages that have different operator precedence rules then brackets are helpful for clarity, IMO. I'd hold that generally too. The above is not so complex but, e.g., a=b*c/d*e+f can have many meanings if you intend parts of the equation to be evaluated in a certain sequence the language's operator precedence differs from. 6. a) [function structure] type function(type arg1) { declarations; code; return; } but as long as it's clear i don't mind. Nov 14 '05 #13

 P: n/a Papadopoulos Giannis wrote: Which do you think is best? 1. a) type* p; b) type *p; b, because type* p, q, r; makes you want to think type *p, *q, *r; 2. a) return (var); b) return(var); c) return var; c, why not ? 3. a) return (ptr->var); b) return(ptr->var); c) return ptr->var; c, same same. 4. a) return (foo(ptr->var)); b) return(foo(ptr->var)); c) return foo(ptr->var); c, same same. 5. a) a = (b+c); b) a=(b+c); c) a = b+c; d) a=b+c; e) a = b + c; 6. E) type foo(type arg1, type arg2, ...) { declarations; code; return; } -- pete Nov 14 '05 #14

 P: n/a Papadopoulos Giannis wrote: Which do you think is best? 1. a) type* p; b) type *p; b) for obvious reasons: type* p, q; 2. a) return (var); b) return(var); c) return var; c) there is no reason to put parentheses around expressions, otherwise I would write return (((var))); 3. a) return (ptr->var); b) return(ptr->var); c) return ptr->var; c) there is no reason to put parentheses around expressions, otherwise I would write return (((ptr)->var)); 4. a) return (foo(ptr->var)); b) return(foo(ptr->var)); c) return foo(ptr->var); c) here is no reason to put parentheses around expressions, otherwise I would write return (((foo)((ptr)->var))); 5. a) a = (b+c); b) a=(b+c); c) a = b+c; d) a=b+c; None of the above. a = b + c; 6. a) type foo(type arg1, type arg2, ...) { declarations; code; return; } b) type foo(type arg1, type arg2, ...) { declarations; code; return; } c) type foo(type arg1, type arg2, ...) { declarations; code; return; } d) type foo(type arg1, type arg2, ...) { declarations; code; return; } e) type foo(type arg1, type arg2, ...) { declarations; code; return; } f) type foo(type arg1, type arg2, ...) { declarations; code; return; } none of the above type foo(type arg1, type arg2, ...) { type Result; declarations; code; return Result; } and don't use \t to indent code that I post. Kurt Nov 14 '05 #15

 P: n/a "Papadopoulos Giannis" wrote in message news:bv***********@ulysses.noc.ntua.gr... Which do you think is best? 1. a) type* p; b) type *p; type* p I never use the comma operator since I have every variable on it's own line so I don't have to worry about the "type* p, q" problem. As for braces, I know there is a "correct" way but doesn't indenting the braces with the code make more sense? if (...) { code; } makes more sense to me since an if() is followed by a statement which may or may not be a compound statement. If you indent the statement, then the braces (which are part of the compound statement, not part of the if() should be indented as well. Also, the above is easier on the eyes to read since you read the if() then read straight down the code. No jumping back and forth. Either way, I know it is personal preference. Jim Nov 14 '05 #16

 P: n/a "Jim Lambert" wrote in message news:Fq****************@eagle.america.net... "Papadopoulos Giannis" wrote in message news:bv***********@ulysses.noc.ntua.gr... Which do you think is best? 1. a) type* p; b) type *p; type* p I never use the comma operator since I have every variable on it's own line so I don't have to worry about the "type* p, q" problem. So you'd write type* p, * q, r; ??? That seems a bit odd... Tom Nov 14 '05 #17

 P: n/a "Tom St Denis" wrote in message news:dU******************@news01.bloor.is.net.cabl e.rogers.com... "Jim Lambert" wrote in message news:Fq****************@eagle.america.net... "Papadopoulos Giannis" wrote in message news:bv***********@ulysses.noc.ntua.gr... Which do you think is best? 1. a) type* p; b) type *p; type* p I never use the comma operator since I have every variable on it's own line so I don't have to worry about the "type* p, q" problem. So you'd write type* p, * q, r; ??? That seems a bit odd... Tom No, I mean I would write... type* p; type* q; type* r; Jim Nov 14 '05 #18

 P: n/a "Jim Lambert" wrote: "Papadopoulos Giannis" wrote in message news:bv***********@ulysses.noc.ntua.gr... Which do you think is best? 1. a) type* p; b) type *p; type* p I never use the comma operator since I have every variable on it's own line Neither do those of use who have more identifiers on a line; those commas are separators, not the comma operator... As for braces, I know there is a "correct" way Well, only for values of correct that amount to "agrees with me". Not for values of correct that mean "can be proven to be the only right one". but doesn't indenting the braces with the code make more sense? if (...) { code; } Ew, no! That way you're guaranteed to overlook the braces in a more complicated compound statement. Richard Nov 14 '05 #19

 P: n/a Papadopoulos Giannis wrote in news:bv***********@ulysses.noc.ntua.gr: Which do you think is best? 1. a) type* p; b) type *p; a 2. a) return (var); b) return(var); c) return var; c 3. a) return (ptr->var); b) return(ptr->var); c) return ptr->var; c but how is this notably different from 2? 4. a) return (foo(ptr->var)); b) return(foo(ptr->var)); c) return foo(ptr->var); c and again... 5. a) a = (b+c); b) a=(b+c); c) a = b+c; d) a=b+c; e) a = b + c; 6. a) type foo(type arg1, type arg2, ...) { declarations; code; return; } b) type foo(type arg1, type arg2, ...) { declarations; code; return; } c) type foo(type arg1, type arg2, ...) { declarations; code; return; } d) type foo(type arg1, type arg2, ...) { declarations; code; return; } e) type foo(type arg1, type arg2, ...) { declarations; code; return; } f) type foo(type arg1, type arg2, ...) { declarations; code; return; } d -- - Mark -> -- Nov 14 '05 #20

 P: n/a "Jim Lambert" wrote in news:b6****************@eagle.america.net: No, I mean I would write... And here comes junior programmer dude... "I'll just add another pointer type here..." type* p, anotherPointer; type* q; type* r; "Hey, I got a 'type' instead of a 'pointer to type', what gives?" -- - Mark -> -- Nov 14 '05 #21

 P: n/a "Mark A. Odell" wrote in message news:Xn********************************@130.133.1. 4... "Jim Lambert" wrote in news:b6****************@eagle.america.net: No, I mean I would write... And here comes junior programmer dude... "I'll just add another pointer type here..." type* p, anotherPointer; type* q; type* r; "Hey, I got a 'type' instead of a 'pointer to type', what gives?" True, JPD could do that but he could just as easily do it with the * being next to the p instead of the type. :-) Nov 14 '05 #22

 P: n/a Nick Landsberg wrote: It's a matter of personal preference. If someone doesn't like the way you do it, let them write a "pretty printer" to reformat it. Why re-writing something that exists and is free ?-) Bruno Nov 14 '05 #23

 P: n/a Papadopoulos Giannis wrote: Which do you think is best? 1. a) type* p; b) type *p; b if you write C code (in C++, the idiom is a) 2. a) return (var); b) return(var); c) return var; c, of course. 3. a) return (ptr->var); b) return(ptr->var); c) return ptr->var; c, of course. 4. a) return (foo(ptr->var)); b) return(foo(ptr->var)); c) return foo(ptr->var); c, of course. 5. a) a = (b+c); b) a=(b+c); c) a = b+c; d) a=b+c; None. The One Right Way(tm) is a = b + c; 6. (snip) d) type foo(type arg1, type arg2, ...) { declarations; code; return; } (snip) But all this is pretty 1/ a matter of taste 2/ more or less language specific Bruno Nov 14 '05 #24

 P: n/a "Richard Bos" wrote in message c), return is not a function. Though you want to ask why you are returning the return value from another function directly - this is unusual. Not at all. The function containing the return statement could be a function which prepares the data for foo(). So there are exceptions. As a rule of thumb, however, if a function calls another function that returns a value, then the caller is the appropriate level to process that value - not simply to return it to a higher level. If you need to prepare data for foo() then that would be an indication that foo() is badly written. Just an indication, mind you, there might be some cases where the problems of formatting input neatly are so deep-rooted that foo() needs a setup function.. My recent MiniBasic program was over 3000 lines. I don't think there is a single case of returning a sub-function's value directly in all that code. Nov 14 '05 #25

 P: n/a "Malcolm" wrote: "Richard Bos" wrote in message c), return is not a function. Though you want to ask why you are returning the return value from another function directly - this is unusual. Not at all. The function containing the return statement could be a function which prepares the data for foo(). So there are exceptions. As a rule of thumb, however, if a function calls another function that returns a value, then the caller is the appropriate level to process that value - not simply to return it to a higher level. Any reasons for that statement? If you need to prepare data for foo() then that would be an indication that foo() is badly written. Nonsense. Look at the example I gave: it could easily be an indication that foo() can work on any data, and the calling function uses it to work on specific data. Richard Nov 14 '05 #26

 P: n/a On Tue, 27 Jan 2004 22:57:04 -0000, "Malcolm" wrote: "Richard Bos" wrote in message > c), return is not a function. Though you want to ask why you are > returning the return value from another function directly - this is > unusual. Not at all. The function containing the return statement could be a function which prepares the data for foo().So there are exceptions. As a rule of thumb, however, if a function callsanother function that returns a value, then the caller is the appropriatelevel to process that value - not simply to return it to a higher level.If you need to prepare data for foo() then that would be an indication thatfoo() is badly written. Just an indication, mind you, there might be somecases where the problems of formatting input neatly are so deep-rooted thatfoo() needs a setup function. Bullshit. There are many useful and valid reasons to return foo(). My recent MiniBasic program was over 3000 lines. I don't think there is asingle case of returning a sub-function's value directly in all that code. My current application is over 1,000,000 lines. And there are quite a few functions that return foo(), for various reasons (some elegant, some for readability, and some just old and gnarly). So there! - Sev Nov 14 '05 #27

 P: n/a Richard Bos wrote: "Malcolm" wrote: .... snip ... Any reasons for that statement? If you need to prepare data for foo() then that would be an indication that foo() is badly written. Nonsense. Look at the example I gave: it could easily be an indication that foo() can work on any data, and the calling function uses it to work on specific data. Example: /* function with side effects returning 0/1 for success/fail */ int foo(/* params */) { ... if (conditions) return 0; else if (failurecondition) return 1; else { .... return foo(/* revised params */); } } Yes, it can easily have recursion removed. -- Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! Nov 14 '05 #28

 P: n/a On Tue, 27 Jan 2004 22:57:04 -0000, "Malcolm" wrote: If you need to prepare data for foo() then that would be an indication thatfoo() is badly written. No, it simply means that the data you have is not appropriate for foo() without preparation. foo() may be common processing for data in more than one form, or foo() may be a standard library function. -- Al Balmer Balmer Consulting re************************@att.net Nov 14 '05 #29

 P: n/a Papadopoulos Giannis wrote: 1. a) type* p; b) type *p; B 2. a) return (var); b) return(var); c) return var; B 3. a) return (ptr->var); b) return(ptr->var); c) return ptr->var; B 4. a) return (foo(ptr->var)); b) return(foo(ptr->var)); c) return foo(ptr->var); B 5. a) a = (b+c); b) a=(b+c); c) a = b+c; d) a=b+c; None. I use "a = b + c;" 6. a) type foo(type arg1, type arg2, ...) { declarations; code; return; } b) type foo(type arg1, type arg2, ...) { declarations; code; return; } c) type foo(type arg1, type arg2, ...) { declarations; code; return; } d) type foo(type arg1, type arg2, ...) { declarations; code; return; } e) type foo(type arg1, type arg2, ...) { declarations; code; return; } f) type foo(type arg1, type arg2, ...) { declarations; code; return; } B -- gabriel Nov 14 '05 #31

 P: n/a Papadopoulos Giannis wrote: Which do you think is best? [...] LOL! I wrote my own reply, and the started to notice some of the other replies... Jeez! Some people even pick fights over this without an opponent! Gotta loooove C programmers! -- gabriel Nov 14 '05 #32

 P: n/a > I never use the comma operator since I have every variable on it's own line so I don't have to worry about the "type* p, q" problem. The comma in "type* p, q" is NOT an operator. Nov 14 '05 #33

 P: n/a Papadopoulos Giannis wrote: Which do you think is best? 1. a) type* p; b) type *p; Always the second. This is made clear in when you have multiple declarers: char *p, q, c, *x; If the * were moved next to the type, you can see how this might be confusing. 2, 3, 4. a) return (var); b) return(var); c) return var; c) is correct and requires fewer characters. Otherwise there is no difference. 5. a) a = (b+c); b) a=(b+c); c) a = b+c; d) a=b+c; I prefer a = b + c; which I guess is closest to choice c). You should only use extra parenthesis where one is intending to be explicit about the order of operations. 6. (spacing, and parentheses for functions ...) I usually put an extra space between declarations and code, however I don't add an extra one for the return (especially since a function might return from any number of places from within the code.) So my style would be closest to: type foo(type arg1, type arg2, ...) { declarations; code; return ...; } -- Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/ Nov 14 '05 #34

 P: n/a "Malcolm" wrote: c) return foo(ptr->var); c), return is not a function. Though you want to ask why you are returning the return value from another function directly - this is unusual. Its not unusual, and it might be a macro rather than a function. -- Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/ Nov 14 '05 #35

 P: n/a Paul Hsieh wrote: Papadopoulos Giannis wrote:Which do you think is best?1.a) type* p;b) type *p; Always the second. This is made clear in when you have multiple declarers: char *p, q, c, *x; This is considered very *poor* programming style for a number of reasons: 1. you declare variables where constants may be required, 2. your variables are undefined and 3. your variables are undocumented. const char c = 'c'; // character constant char q = '\0'; // character variable const char* const x = "some constant string"; const char* p = &c; // reseatable pointer to a // character constant These *definitions* should be placed as close as possible to the point where they are first used. Nov 14 '05 #36

 P: n/a Paul Hsieh wrote: "Arthur J. O'Dwyer" wrote:On Wed, 28 Jan 2004, E. Robert Tisdale wrote: char c = 'c'; // character constant This was about the point where I realized that this must beanother of Trollsdale's joke posts. Oh, I just read the "From:" part of the message to know that. Why is mr. Tisdale hated so much?? PS. I am new to comp.lang.c Nov 14 '05 #39

 P: n/a Papadopoulos Giannis scribbled the following: Paul Hsieh wrote: "Arthur J. O'Dwyer" wrote:On Wed, 28 Jan 2004, E. Robert Tisdale wrote: char c = 'c'; // character constant This was about the point where I realized that this must beanother of Trollsdale's joke posts. Oh, I just read the "From:" part of the message to know that. Why is mr. Tisdale hated so much?? Because he frequently gives bad advice to others. Not only that, but he sometimes also edits others' posts to make them read what he wanted them to read. -- /-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\ \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/ "Normal is what everyone else is, and you're not." - Dr. Tolian Soran Nov 14 '05 #40

 P: n/a "E. Robert Tisdale" wrote in message news:40**************@jpl.nasa.gov... Paul Hsieh wrote: Papadopoulos Giannis wrote:Which do you think is best?1.a) type* p;b) type *p; Always the second. This is made clear in when you have multiple declarers: char *p, q, c, *x; This is considered very *poor* programming style for a number of reasons: 1. you declare variables where constants may be required, Well I'm assuming you'd have one statement for constants and one for not. E.g. const char *p, c; char q, *x; 2. your variables are undefined and So far. That's just the declaration my friend. 3. your variables are undocumented. True that. But it depends. Sometimes variables are trivial, e.g. "int x" would often be just a "I want to step through an array". const char c = 'c'; // character constant char q = '\0'; // character variable const char* const x = "some constant string"; const char* p = &c; // reseatable pointer to a // character constant These *definitions* should be placed as close as possible to the point where they are first used. Your style is just plain messy. Try writing a function that has say 10 or so variables. Now try maintaining 400 similar functions ;-). Giving them values initially is just plain bad coding [hint constants other than trivial ones should be #define not set in local variables]. I think this is just another "bad advice post" which you seem good at... Tom Nov 14 '05 #41

 P: n/a Papadopoulos Giannis wrote: Paul Hsieh wrote: "Arthur J. O'Dwyer" wrote: On Wed, 28 Jan 2004, E. Robert Tisdale wrote: char c = 'c'; // character constant This was about the point where I realized that this must be another of Trollsdale's joke posts. Oh, I just read the "From:" part of the message to know that. Why is mr. Tisdale hated so much?? As Joona has said, because of his virtually universal bad advice, and especially because of his habit of altering quotations of other posters. This means he has to be watched and rebutted continuously, just so newbies such as yourself don't get misinformed. We can't just plonk and forget him. Like BullSchildt, he often sounds good to the uninformed. -- Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! Nov 14 '05 #42

 P: n/a On Thu, 29 Jan 2004 12:25:18 +0000, CBFalconer wrote: Papadopoulos Giannis wrote: Paul Hsieh wrote: > "Arthur J. O'Dwyer" wrote: >> On Wed, 28 Jan 2004, E. Robert Tisdale wrote: >> >>> char c = 'c'; // character constant >> >> This was about the point where I realized that this must be another >> of Trollsdale's joke posts. > > Oh, I just read the "From:" part of the message to know that. Why is mr. Tisdale hated so much?? As Joona has said, because of his virtually universal bad advice, and especially because of his habit of altering quotations of other posters. This means he has to be watched and rebutted continuously, just so newbies such as yourself don't get misinformed. We can't just plonk and forget him. Like BullSchildt, he often sounds good to the uninformed. For what it's worth, as a lurker who seldom posts, I don't hate Tisdale at all. He's one of the posters I sometimes look for in clc, if he's gotten a response from a clued regular. He is most certainly a troll, and most of his "advice" is ludicrous, but this means he often provides a laugh. Also, because (as Chuck says) clued regulars rebut him, newbies get to see some good advice as a result of ERTroll's bad advice. OTOH, his dishonest habit of editing others' posts is disturbing. It's one thing to know that you shouldn't trust what he says. It's much worse to know that you can't trust that people have said what he quotes them as saying. Perhaps he could get a job with a major U.S. newspaper. Nov 14 '05 #43

 P: n/a Papadopoulos Giannis wrote: Why is mr. Tisdale hated so much?? "Hate" is, in my opinion, too strong a word. Suffice to say that his knowledge of C is rather shaky, compared to his determination to give advice about it. If he could only learn, he might even become... well, given his past track-record, there is no point in speculating on that possibility. PS. I am new to comp.lang.c For a while at least, read every article you find. After a while, you'll get a feel for who knows what they're talking about and who doesn't. -- Richard Heathfield : bi****@eton.powernet.co.uk "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html K&R answers, C books, etc: http://users.powernet.co.uk/eton Nov 14 '05 #44

 P: n/a Tom St Denis wrote: Well I'm assuming you'd have one statement for constants and one for not. E.g. const char *p, c; cat main.c #include int main(int argc, char* argv[]) { const char *p, c; p = NULL; c = 'c'; return 0; } gcc -Wall -std=c99 -pedantic -o main main.c main.c: In function `main': main.c:6: warning: assignment of read-only variable `c' Nov 14 '05 #45