Thread: Horribly Formatted Code??

  1. #16
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by taazz
    Considering that they are a good example of bad code using them constitutes a bad habit
    Sure, but I don't see your justification as to why they are "bad code" to begin with. Merely stating an opinion does not make it fact.

    Quote Originally Posted by taazz
    Unintelligent design is because in order to have those working you have to alter the compiler to recognize them in which case you should have added some intelligent optimization instead of introducing oddities like that.
    But they are not odd: they are syntactic sugar that express the intention more clearly and succinctly. That they used to have a part in optimisation is secondary and hence a red herring where programming language design is concerned.

    Quote Originally Posted by taazz
    they are as clear as an algebraic symbol. If you know what it does its clear if you do not its not, in contrast with i = i+1 which is always clear regardless if you know c/c++ or not.
    No, it isn't: I have an old school mate who kept stumbling with simple expressions such as i = i + 1 because it simply does not make sense in algebra: i is never equal to i + 1. In other words, the reader has to understand that "=" means "assign", and if so, it is not a stretch to understand that "+=" means "add then assign".

    Quote Originally Posted by taazz
    the first version of this function was written in asm and it was a direct call to the inc instruction instead of add with an instruction to move the incoming value to the output register the next version added some overflow checking as well. In modern compilers with better optimization it was converted to allow the compiler to optimize it and left there for compatibility reasons.
    Hmm... but if it is a function rather than a macro, how did you get away with not passing a pointer?
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  2. #17
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    Hmm... but if it is a function rather than a macro, how did you get away with not passing a pointer?
    O_o

    I've been waiting on the definition myself, but I've now reread the thread with the last comment "move the incoming value to the output register" in mind.

    I think "i = i + 1 or inc(i)" actually means `i = i + 1` or `i = inc(i)` not the `i = i + 1` or `inc(i)` we thought.

    [Edit]
    But they are not odd
    Even more than that really, every operator could be argued as semantic sugar for an intrinsic or a function.
    [/Edit]

    Soma
    “Salem Was Wrong!” -- Pedant Necromancer
    “Four isn't random!” -- Gibbering Mouther

  3. #18
    Registered User taazz's Avatar
    Join Date
    May 2016
    Posts
    50
    Quote Originally Posted by laserlight View Post
    Sure, but I don't see your justification as to why they are "bad code" to begin with. Merely stating an opinion does not make it fact.


    But they are not odd: they are syntactic sugar that express the intention more clearly and succinctly.
    as you say repeating an opinion does not make it a fact.
    Quote Originally Posted by laserlight View Post
    That they used to have a part in optimisation is secondary and hence a red herring where programming language design is concerned.
    Actually no with out the optimization its even more insane, they add nothing to the overall reading information.
    Quote Originally Posted by laserlight View Post
    No, it isn't: I have an old school mate who kept stumbling with simple expressions such as i = i + 1
    a statistic sample of one is no sample at all. We do have a basic understanding of statistics and the difference between extrapolating data and cooking data right?
    Quote Originally Posted by laserlight View Post
    because it simply does not make sense in algebra: i is never equal to i + 1.
    true then again that means that your friend had no programming experience at all.
    Quote Originally Posted by laserlight View Post
    In other words, the reader has to understand that "=" means "assign", and if so, it is not a stretch to understand that "+=" means "add then assign".
    Actually that's an other bad design in C. It is logical to change the assignment operator to "==" instead of the equal operator.
    Quote Originally Posted by laserlight View Post
    Hmm... but if it is a function rather than a macro, how did you get away with not passing a pointer?
    Calling convention. The compiler I used at that time I could define how a value is to be passed, in, out or inout and "in" parameters will be passed by value if they are equal or smaller of the size of a register (16bit at that time). If my memory serves me right that was true for the first 4 parameters. Keep in mind it had nothing to do with C.

  4. #19
    Registered User taazz's Avatar
    Join Date
    May 2016
    Posts
    50
    Quote Originally Posted by phantomotap View Post
    O_o
    I think "i = i + 1 or inc(i)" actually means `i = i + 1` or `i = inc(i)` not the `i = i + 1` or `inc(i)` we thought.
    You are right my version of the function was actually used as i = inc(i);

  5. #20
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by taazz
    as you say repeating an opinion does not make it a fact.
    I gave the reasons behind my opinion in post #12.

    Quote Originally Posted by taazz
    they add nothing to the overall reading information.
    That's the point of syntactic sugar: syntactic sugar never adds anything to the overall information conveyed by the code, but rather makes the code easier to read and write. Contrast:
    Code:
    for (i = 0; i < n; ++i)
    and:
    Code:
    for (i = 0; i < n; i += 1)
    with:
    Code:
    for (i = 0; i < n; i = i + 1)
    The first snippet is instantly recognisable as an incrementing for loop. The second snippet is instantly recognisable as a for loop that has step increment, and on closer inspection the step is 1, so it is just a normal incrementing for loop. The third snippet requires the reader to check a bit more carefully that the pattern is indeed incrementing. Nothing changes as to the overall information conveyed by the code: it is an incrementing for loop no matter which snippet.

    Quote Originally Posted by taazz
    a statistic sample of one is no sample at all. We do have a basic understanding of statistics and the difference between extrapolating data and cooking data right?
    No, it is a counterexample which is sufficient to disprove your universal claim.

    Quote Originally Posted by taazz
    true then again that means that your friend had no programming experience at all.
    Exactly. My school mate was starting on her very first foray into programming. That's the point. Any experienced programmer should be able to adapt to mere syntax, so using an experienced programmer's intuition is not so helpful: for example, a Python programmer coming into C programming would be familiar with "+=".

    Quote Originally Posted by taazz
    Actually that's an other bad design in C. It is logical to change the assignment operator to "==" instead of the equal operator.
    You are probably thinking of the common bug where "=" is substituted for "==" or vice versa, but part of that problem lies with assignments being expressions having a result of a non-void type. This allows for chaining, but the most common form of the mistake is in a condition, where if they did not have a result, there could be an error instead of silently permitting the mistake (though of course modern compilers do complain, especially at higher warning levels). On the other hand, chaining can indeed be useful for concise code, though I would propose ":=" from an older programming language rather than "==" because you essentially end up with the same problem if you swapped the semantics of "=" and "==", but anyway it is what it is now.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  6. #21
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    If you know what it does its clear if you do not its not, in contrast with i = i+1 which is always clear regardless if you know c/c++ or not.
    Since when do we cater to people who can't read C code at all?

    Why would that be a strong argument on this forum? Think about where you are.

  7. #22
    Registered User
    Join Date
    Nov 2012
    Posts
    1,393
    Quote Originally Posted by nadeera View Post
    I was wondering if anyone could tell me what is a horribly formatted code and what are "well" formatted codes supposed to look like?
    Try running your code through the indent program (use the -kr option). If the output looks very different from the input, it may be poorly formatted.

  8. #23
    Registered User rstanley's Avatar
    Join Date
    Jun 2014
    Location
    New York, NY
    Posts
    1,106
    Quote Originally Posted by c99tutorial View Post
    Try running your code through the indent program (use the -kr option). If the output looks very different from the input, it may be poorly formatted.
    The current version, 2.2.11, of indent, is far outdated. Mainly from 2008 with some minor changes in 2010. I would strongly recommend using a good programmers editor, such as vi/vim or emacs, or an IDE and use the features of the editor to control the formatting as you type.

    As for the -kr option, that is only one style of many that the individual would need to choose from for new projects, or if maintaining an existing project, the style that has been established for that project. See the Wikipedia article on Indent Style for a list of indentation styles and samples.

  9. #24
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    The current version, 2.2.11, of indent, is far outdated. Mainly from 2008 with some minor changes in 2010.
    as far as I can tell, the only reason anyone would want to make a new version of indent is to keep up a sense of perceived newness that doesn't actually matter. Perhaps there hasn't been a new version because indent style is the same and the program itself isn't broken.
    I would strongly recommend using a good programmers editor, such as vi/vim or emacs,
    You're probably sick of me disagreeing at this point, but I sincerely hope that the OP avoids all of these editors. It seems to be a masochistic tradition of programmers to recommend vi and emacs clones. Plus, I'm tired of hearing "pick a good editor" as everyone's answer to this problem. Most editors suck and need assistance in such a way that the programmer wants to indent in the first place! It's much more important to see indent styles with actual code, so people really see it for what it is, in my opinion, and I think the indent program helps with that.

    *It certainly helps me format bad code on here quickly and without real thought.*
    Last edited by whiteflags; 08-05-2016 at 10:10 PM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Formatted output %*s
    By dtow1 in forum C Programming
    Replies: 3
    Last Post: 12-15-2012, 12:29 PM
  2. Replies: 4
    Last Post: 04-10-2006, 05:43 PM
  3. formatted output
    By Magica in forum C Programming
    Replies: 3
    Last Post: 05-11-2003, 11:36 PM
  4. Please help with formatted I/O
    By ucme_me in forum C Programming
    Replies: 9
    Last Post: 12-07-2001, 09:10 AM
  5. formatted I/O
    By Unregistered in forum C Programming
    Replies: 0
    Last Post: 12-05-2001, 08:05 PM

Tags for this Thread