Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Source Formatter
Michael:
--- Quote from: thomas on January 15, 2006, 06:07:44 pm ---
--- Quote from: Michael on January 15, 2006, 05:53:17 pm ---Sorry, but why you want to hard code it :?? IMHO, it is not a very good idea, because of e.g., extensibility, scalability.
--- End quote ---
Hey, hardcoding is great :)
(For me, that is, since I only use C++)
--- End quote ---
Hard coding is useful, I agree :), but not when the code would change oft and/or for extensibility/scalability. In such a case, it is better to avoid hard coding even if the implementation would take some more time. But later, you will save time when modifiying/updating the code.
--- Quote from: thomas on January 15, 2006, 06:07:44 pm ---I'd love to see a better source code formatter for C++. And since hardcoding the lexer saves Ceniza precious time, this means he'll be done with it sooner (and I'll be happy sooner :))
--- End quote ---
Well, I cannot really disagree with you :D. May be, later it would be possible to re-write the hard-coded part.
Michael
rickg22:
My state machine in the copystrings plugin is hardcoded, my point was the design without special cases (in a state machine, all cases are special cases - they're handled equally).
If what Ceniza meant by "hardcoding" was to use a series of if's and design of the lexer/parser "by hand", then that's a no-no.
Ceniza:
--- Quote from: thomas ---I'd love to see a better source code formatter for C++. And since hardcoding the lexer saves Ceniza precious time, this means he'll be done with it sooner (and I'll be happy sooner :))
--- End quote ---
Oh, my precious... time.... I would like to get it done soon too :)
There's something I prefer to ask you guys, and girls if any: how to customize it? I mean, how detailed would you like it to be? Any interface idea?
So far I've thought of a series of dialogs, each one to customize specific things (but I also think it would be overkill, even to configure), like the way a "if (expr) stmts", "if (expr) { stmts }", the ones with "else" and "else if" should be formatted. You could then "say", for each thing: the if goes in a new line with current indentation, space + LPAREN, expr, RPAREN, LBRACE in new line with current indentation, stmts in new line with extra indentation, RBRACE in new line un-indenting, ...
That way it would always look like this:
--- Code: ---if (expr)
{
stmts
}
--- End code ---
Or just use simple options similar to those in AStyle?
Ideas? I still need to add a few more things to the lexer and have a global idea of the parser, including "customization details", before I can start coding it.
rickg22: I think it's a no-no then, sorry :P
Michael:
--- Quote from: Ceniza on January 16, 2006, 07:30:49 pm ---Or just use simple options similar to those in AStyle?
--- End quote ---
I do not know what the other devs/users think about, but for my AStyle was quite good :D. I just set the template I wanted to use (ANSI :lol:) and voilà...
The custom option of AStyle is a good idea. So, users could use their own style.
What it would be also good, would be the possibility to define and register new styles. In this was users could define more than one custom style.
IMHO, the code should also thought extensible and scalable to allow integration of e.g., another parser.
Michael
thomas:
The AStyle way is not so bad actually, it is simple and it works. But there are just a few things which AStyled does not do the way I like it (for example, it compresses white space in comments and around '=', and always puts {} in a new line, so if you spend a lot of time laying out things properly, the code formatter destroys it later). Also you can only configure everything from hand, or nothing, which is annoying (for example, I like the way ANSI style looks, but I don't like spaces for indentation).
Why don't you make a simple "choose one out of n" interface (list box, for example). The actual configuration is read in from a config file, and you just provide 3-4 such configs. If somebody wants something different from ANSI, Gnu, or K&R, then he can write his own config and is not limited to a stiff GUI. Most people will use one of the default sets, so they have a 1-click configuration.
You could use tinyXML for the parsing, so you save an awful lot of time on designing a GUI (designing a GUI takes 90% of your time, but only 10% of the people use it 1% of their time...).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version