I wouldn't trust an automated tool that can't properly parse code, eh. Besides K&R is widely used.
Printable View
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_OQuote:
Originally Posted by Mario F.
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.Quote:
Originally Posted by SlyMaelstrom
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.
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.
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. ;)
As you can probably tell from the above command, I use "underscore notation". I also put opening curly braces on the previous line.Code:cat code.c | indent - | program_that_assumes_curly_braces_on_separate_lines
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 likeQuote:
Originally Posted by Mario F.
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. :)Code:enum { clubs, diamonds, hearts, spades } suit;
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! :p )
[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]
But what if the code is syntactically incorrect? That's no reason not to be able to index it.Quote:
Originally Posted by Mario F.
"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.
Except that it is, what if I wanted to use the parser on existing code?Quote:
Originally Posted by brewbuck
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.
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.Quote:
Originally Posted by abachler
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.Quote:
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'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
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.Quote:
Originally Posted by brewbuck
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.Quote:
Originally Posted by SlyMaelstrom
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
My experience, functioning on various development teams, is that complexity often looks "worth it" but rarely is.Quote:
I am still a very young programmer and would expect better from a team of developers.
Your opinion is perfectly valid, no need to apologize for it.Quote:
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.
I can see your point here brewbuck. It begs a rebuttal, though :)Quote:
Originally Posted by brewbuck
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.
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.Quote:
Originally Posted by brewbuck
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.Quote:
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.