Related articles |
---|
coding conventions a7244270@yahoo.com (2003-02-05) |
Re: coding conventions alexc@world.std.com (2003-02-11) |
Re: coding conventions a7244270@yahoo.com (2003-02-21) |
Re: coding conventions s.bosscher@student.tudelft.nl (2003-02-24) |
From: | s.bosscher@student.tudelft.nl (Steven Bosscher) |
Newsgroups: | comp.compilers |
Date: | 24 Feb 2003 13:51:15 -0500 |
Organization: | http://groups.google.com/ |
References: | 03-02-009 03-02-065 |
Keywords: | yacc, practice |
Posted-Date: | 24 Feb 2003 13:51:15 EST |
alexc@world.std.com (Alex Colvin) wrote in message news:03-02-065...
> >I'm fairly new to this flex/bison stuff, and I was wondering - is
> >there a recommended coding convention for flex/bison ? like for
> >example should I have named the "subpart" differently, etc.
---- 8< ----
> I don't have any formal style guide, but I'll push the convention that the
> yacc actions should be kept as short as possible, either an assignment or
> a function call. Not only does long precedural code make the grammar hard
> to follow, but you don't want to put anything you might need to debug in
> your *.y file.
I agree that the yacc actions should be short, because it keeps the
grammar clean and readable. I don't see the debugging problem though.
Can you explain that a but further please?
Last time I has to work with a grammar that was stuffed with
production actions, I could step through the code in the .y file in
the debugger. In fact in was quite helpful (but still ugly) that the
code was in the grammar because you can see which production you were
in.
Greetz
Steven
Return to the
comp.compilers page.
Search the
comp.compilers archives again.