Thread: this_is_my_variable_name

  1. #16
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    I wouldn't trust an automated tool that can't properly parse code, eh. Besides K&R is widely used.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  2. #17
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,079
    Quote Originally Posted by Mario F. View Post
    I wouldn't trust an automated tool that can't properly parse code, eh. Besides K&R is widely used.
    Yeah, honestly... can you imagine if the compiler couldn't parse the code unless the open brace was in the first column? O_O

    That's just lazy design. Why make a tool designed to parse through C code that doesn't conform to C's standard on whitespace?
    Last edited by SlyMaelstrom; 04-09-2008 at 10:44 AM.
    Sent from my iPadŽ

  3. #18
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by SlyMaelstrom View Post
    Yeah, honestly... can you imagine if the compiler couldn't parse the code unless the open brace was in the first column? O_O

    That's just lazy design. Why make a tool designed to parse through C code that doesn't conform to C's standard on whitespace?
    Lots of tools do it. The reasons are speed and flexibility. You can do a lot of useful source indexing without having to actually parse the language. The benefit gained is that the tool will automatically work on ANY language which is "C-like," including C++, Java, JavaScript, C#, and PHP -- provided the code being processed adheres to a single, simple rule.

    It's not lazy -- it's deliberate.

    EDIT: Also, you should try writing a parser which can recognize the beginning of a function definition... In C++. Just wait until templates get involved. By the end of this task you'll essentially have written a compiler, when all you wanted to do was a little source indexing. It is not a bad choice to ignore the entire issue and specify that the input must conform to a simple rule, a rule which isn't even that onerous.
    Last edited by brewbuck; 04-09-2008 at 11:15 AM.

  4. #19
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Dunno brewbuck, maybe you are right. But even the poor-man refactoring tool I sometimes uses properly recognizes K&R.

    I insist. If you are being forced to use these tools you are talking about, get into a strike.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #20
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    I dunno. Have you ever seen Doxygen's yacc/bison parser? It handles C, C++, Java, and I think ML and other languages all in one parser. Let me tell you, it's ugly.

    Besides, if your code doesn't conform to this rule, whatever it is, you can always pass the code through indent. Let indent do the full parsing, not you.
    Code:
    cat code.c | indent - | program_that_assumes_curly_braces_on_separate_lines
    As you can probably tell from the above command, I use "underscore notation". I also put opening curly braces on the previous line.

    Quote Originally Posted by Mario F.
    and I'm yet to be consistent around enumerations (can somebody suggest something I end up liking?).
    Just that enum values should always have a prefix. I use all capitals for them on the grounds that they're constants as well. But whatever you use, do use a consistent prefix. Nothing annoys me more than code like
    Code:
    enum { clubs, diamonds, hearts, spades } suit;
    because it's hard to tell what "clubs" is. What do you know -- I must partially subscribe to the ideals of camel notation, in putting information about a symbol into its name.

    But no, I prefer not to use camel notation on the grounds of readability. It's simply easier for the eye to separate_this_into_words thanThisIntoWords.

    I don't hate camel notation, though -- I use the SDL frequently, and I've never considered writing a layer to re-defined its camel-notation names into underscore notation.

    (Note that I invented the term "underscore notation". I'm sure it's not very widespread, so don't use it without explaining what it means first! )

    [edit] Did manav just get banned? I could have sworn that his/her user title wasn't "Banned" when I loaded this thread for the first time . . . . [/edit]
    [edit=2] Aha! It wasn't on the 28th of March. http://72.14.253.104/search?q=cache:...lnk&cd=2&gl=ca [/edit]
    Last edited by dwks; 04-09-2008 at 11:42 AM.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  6. #21
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by Mario F. View Post
    Dunno brewbuck, maybe you are right. But even the poor-man refactoring tool I sometimes uses properly recognizes K&R.

    I insist. If you are being forced to use these tools you are talking about, get into a strike.
    But what if the code is syntactically incorrect? That's no reason not to be able to index it.

    "Why on earth would you have code that is syntactically incorrect" -- because it might be hiding inside an #ifdef, currently disabled, so you don't notice it's broken. Again, no reason not to index it.

    At work the only indexing tool I really use is cscope. Its parser is a little more complex/robust that just "look for opening curly brace on column 1," but it still doesn't fully parse the language, because that would be too restrictive. You want your indexing tools to work properly even when you use non-standard language extensions or other oddities which would completely confuse a "real" parser.

  7. #22
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by brewbuck View Post
    It is not a bad choice to ignore the entire issue and specify that the input must conform to a simple rule, a rule which isn't even that onerous.
    Except that it is, what if I wanted to use the parser on existing code?

    Its not that difficult to write a parser that properly parses every style of C/C++ code. Its certainly less invovled that writing a whole compiler.

  8. #23
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by abachler View Post
    Except that it is, what if I wanted to use the parser on existing code?
    Obviously, if you have some other use for a parser, why not write one? It still doesn't solve the problem of how to deal with malformed code.

    Its not that difficult to write a parser that properly parses every style of C/C++ code. Its certainly less invovled that writing a whole compiler.
    I think the writers of C++ compilers would disagree on the level of difficulty. Look how long it has taken just to get basic template support in most of the compilers.

  9. #24
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,079
    Quote Originally Posted by brewbuck View Post
    Lots of tools do it. The reasons are speed and flexibility. You can do a lot of useful source indexing without having to actually parse the language. The benefit gained is that the tool will automatically work on ANY language which is "C-like," including C++, Java, JavaScript, C#, and PHP -- provided the code being processed adheres to a single, simple rule.

    It's not lazy -- it's deliberate.
    I'm for the opinion that a good program should minimize demand on the end-user. I'd rather a slower program that allows greater flexibility in my input than a quicker program that demands I conform to a standard I wouldn't normally follow. It might even be more time consuming to use the quicker parser if I have to waste time double-checking myself to make sure I didn't conform to my own natural habits. The ability to parse several languages should only make a program more robust in size and not significantly slower in operation. It should generally be a quick enough procedure for a program to identify the language it is parsing. All languages have unique attributes that can be searched for to identify this.
    Quote Originally Posted by brewbuck View Post
    EDIT: Also, you should try writing a parser which can recognize the beginning of a function definition... In C++. Just wait until templates get involved. By the end of this task you'll essentially have written a compiler, when all you wanted to do was a little source indexing. It is not a bad choice to ignore the entire issue and specify that the input must conform to a simple rule, a rule which isn't even that onerous.
    I'm not about to be convinced as to whether something is worth doing or not based on how easily I could achieve it myself... I am still a very young programmer and would expect better from a team of developers. Besides, I so no reason for this to be as slow as a compiler, because you'd be skipping most of the lexical analysis and all of the optimization and rewriting. Look, I don't have a fraction of the experience that you have programming, so I'm not going to bash you ideas down with my simple opinions... however given that abachler and Mario (both who have nearly the experience you have) seem to have similar opinons to mine, I feel as though I'm at least making an acceptable stance on the issue. Who knows... I could be wrong.
    Sent from my iPadŽ

  10. #25
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by SlyMaelstrom View Post
    I'm for the opinion that a good program should minimize demand on the end-user. I'd rather a slower program that allows greater flexibility in my input than a quicker program that demands I conform to a standard I wouldn't normally follow.
    My point is that by implementing a real parser, you DO reduce flexibility, by making it impossible to handle malformed code, code with extensions, or code written in other languages.

    I'm not arguing that the curly-brace-column-1 rule isn't overly simplistic, because it is. A slightly better algorithm that does not require a full-blown parser is to just count the brace nesting level.

    In reality, you will find numerous tools which rely on this for proper functioning, and you'll find numerous development teams which implement this style rule specifically so that these tools will work correctly.

    Hell, you'll even find mention of it in the GNU coding standard itself. Careful as you read this -- they don't state it explicitly, but they do state the contrapositive, which is equivalent. In fact, they apply even more stringent requirements, by requiring that the first character of the function name occur in column 1 -- in other words, you put the return type on a line by itself. I do find that particular rule to be overly restrictive:

    http://www.gnu.org/prep/standards/ht...tml#Formatting

    Quote Originally Posted by GnuCodingStandard
    Avoid putting open-brace, open-parenthesis or open-bracket in column one when they are inside a function, so that they won't start a defun. The open-brace that starts a struct body can go in column one if you find it useful to treat that definition as a defun.

    It is also important for function definitions to start the name of the function in column one. This helps people to search for function definitions, and may also help certain tools recognize them.
    I am still a very young programmer and would expect better from a team of developers.
    My experience, functioning on various development teams, is that complexity often looks "worth it" but rarely is.

    Look, I don't have a fraction of the experience that you have programming, so I'm not going to bash you ideas down with my simple opinions... however given that abachler and Mario (both who have nearly the experience you have) seem to have similar opinons to mine, I feel as though I'm at least making an acceptable stance on the issue. Who knows... I could be wrong.
    Your opinion is perfectly valid, no need to apologize for it.

  11. #26
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by brewbuck View Post
    My point is that by implementing a real parser, you DO reduce flexibility, by making it impossible to handle malformed code, code with extensions, or code written in other languages.
    I can see your point here brewbuck. It begs a rebuttal, though

    Malformed code should be flagged as malformed code. I don't think it is the task of an automated tool (from indexers, to refactors, to code beautifiers even) to try and make some sense of it and guess as to what the coder wanted.

    I would agree that macros, for instance, may force the user as to specific styles in order to make them work on their tool of choice (if the tool even considers them). But other than that, I find it extremelly limiting any tool that forces me to adapt my code to it. If an attempt hadn't been made by parsers to overcome these limitations in the past, we all would be still formating our code to run our refactoring program, then format it again to run our indexer, then format it again to run our document generator.

    All in all, this is becoming less and less of a problem. Every run-of-the-mill code editor these days come with powerful indexing tools. Commercial ones ranging on the hundreds of dollars (which everyone uses anyways) come with even more powerful tools. I would wager those recommendations from the GNU Project are not only old (very), but also plain wrong even for when they were valid; simply because they take the burden of the tool and put it on the user of the tool. This is mal practice.

    Despite that, they probably only apply these days mostly to legacy systems and tools. You can't expect to take anything of that seriously (and judging from GNU recent code no one does) in a world where bison and yacc, for instance, are no longer infants and widely accessible to anyone wanting to code their own tools.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  12. #27
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by brewbuck View Post
    Obviously, if you have some other use for a parser, why not write one? It still doesn't solve the problem of how to deal with malformed code.
    Define malformed, if its not properly formatted int eh first place, then any parser will have problems, if you mean you just dont like the style, then pshaw who cares.

    I think the writers of C++ compilers would disagree on the level of difficulty. Look how long it has taken just to get basic template support in most of the compilers.
    You dont have to write a whole compiler to write a parser. The parser is only one part fo the compiler, and unless it is parsing in preperation fro compilation, you dont need to do as thorough of a job as in a compiler.

Popular pages Recent additions subscribe to a feed