#nowarn directive

ID:1086588
 
Dec 15 2012, 6:18 pm
Applies to:Dream Maker, DM Language
Status: Open
Issue hasn't been assigned a status value.
This preprocessor would stop the outputting of compile-time "warnings".
#nowarn TRUE
mob/verb/pie()
    var/pineapple
#endnowarn //or #nowarn FALSE


This normally would show you an error about pineapple not being used, but defined. With it being enclosed in this preproccessor macro, the warning would be ignored.
Dec 15 2012, 6:21 pm
I don't think a boolean value would be necessary for this, and I guess there's a place for it somewhere.
Dec 15 2012, 9:55 pm
I think it's a bit confusing that it's a boolean value.

does 'no warn' when true show warnings or not?
Dec 15 2012, 10:02 pm
#nowarn TRUE would not show warnings for the entire block up to its ending counterpart.

Though, yeah, maybe a boolean value isn't needed.
Dec 16 2012, 2:59 am
What kind of warnings are you hoping to suppress with this?
Dec 16 2012, 11:21 am
In response to Stephen001
Exactly what I was thinking..
Dec 16 2012, 12:15 pm
In response to Stephen001
Stephen001 wrote:
What kind of warnings are you hoping to suppress with this?

...any warnings.
Dec 16 2012, 12:18 pm
The warnings are there for a reason, however. What I'm interested in, are the warnings you feel are genuinely unhelpful during your writing of reasonable code.
Dec 16 2012, 12:23 pm
Basically things that don't really affect the program,
variable defined but not used
unused label

I'm sure I'm not the only one who defines variables within a procedure for future use, and doesn't want to see warnings for something that's not used yet.
Dec 16 2012, 12:30 pm
In response to Super Saiyan X
You should be the only one, that's not good practice .. if you want the var for future use then write in it at the time of need other wise it's just a variable defined but not used
Dec 16 2012, 12:32 pm
Seems like an odd methodology, but alright. That's exactly what it's reporting them for, it's warning you they are not in use.

My concern is simply this, inappropriate masking of issues with it. The obvious case that springs to mind is deprecation warnings, perhaps more-so in libraries than games, but both applies.

Consider the case where you pull in a library using deprecated procedures, and the acknowledged practice becomes to #nowarn around the library. Which you just know will end up being the route people will take for some text handling libraries, to drop a nice 1000+ warnings very quickly.

The issue is forgotten (as happens when warning suppression is used), and BYOND finally pulls the deprecated procedures. Suddenly on update your game goes bang on compile, and you didn't change anything and BYOND reported no issues to you.

In languages like C or Java, such warning suppression mechanisms exist, but are strongly advised against. In fact in C good practice, you get the compiler to turn any warning into an error precisely to force these things to be sorted by people.

As BYOND is typically more of a learners language, as well as the first language a person will encounter, hiding compiler warnings seems like an anti-pattern. The argument in favour of it would be if the compiler gave very misleading warnings about perfectly good code. Which doesn't seem to be the use-case you have in mind.
Dec 16 2012, 12:41 pm
In response to A.T.H.K
A.T.H.K wrote:
You should be the only one, that's not good practice .. if you want the var for future use then write in it at the time of need other wise it's just a variable defined but not used

In that case, I shouldn't be the only one. No one should. But people do it.
It's not bad practice. I doubt no one writes code and documents it //THIS IS FOR LATER.
Just because something isn't used outside of it's declaration doesn't mean it's not there for something.

other wise it's just a variable defined but not used
Clearly. The warning obviously says that. It's exactly why I want to hide it. It's not warning me of anything that is or will affect me, and I don't want to see warnings about it in that particularly use in that block of code.

Stephen wrote:
snip
Perhaps, it'd only warn if __MAIN__ is defined. i.e. it's included as a library.
Dec 16 2012, 12:42 pm
I think the practice is still pretty iffy, and an anti-pattern in concept.
Dec 20 2012, 7:41 am
Actually, here's an example in a game I worked on, where one of the coders thought this would be a good idea..

                        if(get_dir(src,T)==NORTH)
                            var/obj/wateredges/a/a=new(T)
                        if(get_dir(src,T)==SOUTH)
                            var/obj/wateredges/d/a=new(T)
                        if(get_dir(src,T)==WEST)
                            var/obj/wateredges/b/a=new(T)
                        if(get_dir(src,T)==EAST)
                            var/obj/wateredges/c/a=new(T)
                        if(get_dir(src,T)==NORTHEAST)
                            var/obj/wateredges/f/a=new(T)
                        if(get_dir(src,T)==SOUTHEAST)
                            var/obj/wateredges/g/a=new(T)
                        if(get_dir(src,T)==NORTHWEST)
                            var/obj/wateredges/e/a=new(T)
                        if(get_dir(src,T)==SOUTHWEST)
                            var/obj/wateredges/h/a=new(T)

This was in the New() proc for a water tile, which spawned its edges on all sides.
Yes, there is a better way to go about this, but the point is that it created 8 warnings, and no one wanted to deal with them because they didn't negatively affect the game.
If this feature were added though, it would just make it more acceptable to be lazy..
Dec 20 2012, 7:46 am
That's just poor programming, which is exactly what warnings and errors are there to prevent. The person had no reason to make variables for any of that, they just had to do 'new/obj/wateredges/h(T)'.

Personally, I see this suggestion as a lazy way of not fixing your code.
Jan 9 2013, 2:48 pm
You're essentially asking for a DM-sanctioned way to do bad programming.