|coding conventions firstname.lastname@example.org (2003-02-05)|
|Re: coding conventions email@example.com (2003-02-11)|
|Re: coding conventions firstname.lastname@example.org (2003-02-21)|
|Re: coding conventions email@example.com (2003-02-24)|
|From:||firstname.lastname@example.org (Steven Bosscher)|
|Date:||24 Feb 2003 13:51:15 -0500|
|Posted-Date:||24 Feb 2003 13:51:15 EST|
email@example.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
Return to the
Search the comp.compilers archives again.