I'd noticed we currently have a #error preprocessor directive, that will halt the compilation process and output a given message. This is naturally very nice for sanity checks (like the BYOND version example in the DM reference).
I was wondering if we could get similar functionality for just outputting a compiler warning. I'd imagine this might not get so much use for single-person projects (unless it is perhaps a large code-base, or developer preference). For team projects, you could make use of this preprocessor functionality to make the person compiling aware of say bad practices (by the project's standard) in use, or the use of deprecated procedures and so forth.
I just think it would be nice to add another tool to the arsenal of teams.
ID:133552
 Jun 8 2008, 9:13 am
|
|
|
Jun 8 2008, 9:17 am
|
|
Kaioken
 |
Seconded. This would also be useful for some libraries.
|
I like the idea in general, although I'm a little unsure how you would use this to catch bad practices.
Lummox JR | |
That's not what they are talking about. Those are in-game debug or error messages.
What they are talking about is the #error directive. | |
For something like that you'd have to make it quite different than #error, unless this would work-
#define goto #warning Goto is bad ; goto
-but I wouldn't think so. I thought more like, #ifndef MY_LIBRARY_SETTING_THING Or whatever; having a #warning is also nice just to complement #error. =P We'd also be able to put in "TO-DO" lines more easily than artificially creating warnings with unused vars and the like. Also, I notice #error doesn't add to the error count, but it still stops compilation/doesn't let you run the DMB. This should be fixed, as it can cause confusion. If I see "0 errors", I do expect my DMB to run (although you see the error itself a bit above:) loading test.dme test.dm:21:#error Hello test.dmb - 0 errors, 0 warnings | |
Well, let us pretend we are writing a library. In version 1, we implement /weather_maker/proc/make_rain(var/somevar), that makes rain according to some particular algorithm.
Some people pick up the library and use it. In version 2, we decide that actually, make_rain could be a lot more efficient if we don't allow them to fiddle the rain making process with somevar and they wouldn't need to know how somevar works, because let's say it's just an implementation detail they are fiddling (that is, it breaks encapsulation a bit). Now, it would seem a bit silly as a library developer to assume that people can always just migrate away from fiddling the rain making process with somevar. Although it is an implementation detail we perhaps shouldn't have had there in the first place, some people might rely on it now. So we make /weather_maker/proc/make_std_rain() as our replacement, then put a suitable #warning in make_rain(var/somevar) denoting it is both bad practice (we're assuming this breaking of encapsulation was a design flaw, not something necessary) and won't be supported in the future. People migrating from version 1 can take the other benefits of version 2, while having time to code and test their move to make_std_rain. People new to the library at version 2 will get a warning telling them it is bad practice, so would design their stuff to use the better practice make_std_rain instead. Obviously being a warning, it's only any good if people pay heed to it. However in a team project, you could say that the team doesn't make a release until all these warnings are cleared up, helping ensure easier maintenance. Presumably these warnings were discussed elsewhere by the team, but the compiler warning serves as a last chance for a developer to remember they need to update their code to a new practice. | |
May I suggest #note?
loading mygame.dme mygame.dm:21:#note Need to add the grass turfs mygame.dmb - 0 errors, 0 warnings, 1 note It would clutter up the compiler less. That is, if used with my second suggestion: seperate errors, warnings and notes. You can show/hide them in the final list. This would require a treeview though. -- Data | |
Stephen001 wrote:
So we make /weather_maker/proc/make_std_rain() as our replacement, then put a suitable #warning in make_rain(var/somevar) denoting it is both bad practice Thing is, what Lummox was saying, that wouldn't work as you want it to. Preprocessor directives are all processed and read by the compiler, in compile-time only, so you can't expect that by putting your #warning in a certain proc it will only take effect if that proc is called. It will cause the warning to always be generated, regardless. EDIT: You're right that such an ability could be useful, but we'd need something different than an #error equivalent for warnings for such a thing. Like, perhaps, #warn goto Goto is bad etc. An #unwarn would also be useful for this, for removing a previous #warn (the use would be disabling #warn's of libraries without editing them, when you're aware of what the warning says and know what you're doing). | |
I like this one more than #warning, because it can be used for both warnings and TODO items.
"Note: The make_rain proc is obsolete -- see the new make_std_rain proc" works well as a warning, while "Note: Need to add the grass turfs" works well as a note. More preprocessor directives will slow down compiling ever so slightly, so if I had to pick one or the other, I'd choose the one that can be more generally used. If the effect of adding both was negligible, however, it might as well be both (since #warning would increase the warning count). | |
My mistake, you're right. I've been dealing with Liunx kernel makefile logic too much recently. They essentially use the Makefile to emit warnings when they note a file uses deprecated logic, kind of like my original suggestion.
Data's point with #note is interesting, seen as you're then starting to head towards Java-style annotations. That in itself brings about a whole other debate, but would permit my original suggestion, TODO notes as well as other things. Let's not pretend an annotations-like feature would be entirely trivial to add though. | |