 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2005How many warnings is too many?
I suppose this is a rather odd question but how many warnings is too many when you are using a Java compiler like the one in Eclipse 3.1.1? Using the default settings for the 1.5 compiler in a fresh install of Eclipse 3.1.1, my various projects have over 4000 messages between them, 22 of which are 'errors' that I have yet to repair. The rest are warnings of one kind or another. I could decrease this number substantially by either setting many conditions to 'error' or 'warning' when they are currently 'ignore' or increase it substantially by setting 'ignore' conditions to 'error' or 'warning'. And, of course, I could probably make the vast majority of them go away simply by rewriting code. I'd be surprised if anyone turned _all_ conditions to 'warning' or 'error' and then fixed every single one of the warnings and errors so that the entire workspace was error-free but maybe I'm wrong. That's why I'd like some feedback on just how many errors and warnings is considered okay and what is considered excessive. To put it another way, if you were considering hiring me to write Java for you and asked me for an example of a completed project to inspect, what conditions would YOUR compiler be set to detect and ignore and how many errors and warnings would you consider acceptable? I'm going to guess that the number of errors should always be zero in a completed project - correct me if I'm wrong - but that some warnings would be tolerated, on the theory that fixing every conceivable minor warning is not required to prove that you write good code. Am I close? Can anyone give me guidelines to help me determine just what warnings I should never tolerate and which I should feel free to ignore without making me look like a bad coder?  SignatureRhino > To put it another way, if you were considering hiring me to write Java for > you and asked me for an example of a completed project to inspect, what [quoted text clipped - 4 lines] > the theory that fixing every conceivable minor warning is not required to > prove that you write good code. Am I close? Not quite. I would be more interested in probing a candidate's ability to fix the warnings and errors, and what the candidate had to say about why some of those warnings can be/should be ignored. In general, you should be able to write code that does not generate *any* warnings even with every conceivable flag turned on. In specific instances, some warnings are tolerable, but as a job candidate, you must be able to explain why. YMMV. -- Adam Maass > I suppose this is a rather odd question but how many warnings is too many > when you are using a Java compiler like the one in Eclipse 3.1.1? [quoted text clipped - 26 lines] > should never tolerate and which I should feel free to ignore without making > me look like a bad coder? Working as a US gov't subcontractor I know that the Dept of Justice does not allow any code to be put into operations if it has even 1 warning as a result of a compile. >Working as a US gov't subcontractor I know that the Dept of >Justice does not allow any code to be put into operations if it >has even 1 warning as a result of a compile. This seems to encourage @SuppressWarnings("all") on the outermost elements of every compilation unit. > Working as a US gov't subcontractor I know that the Dept of Justice does > not allow any code to be put into operations if it has even 1 warning as > a result of a compile. "Warning: line 33: getColor(), localised spelling detected in identifier" (Totally imaginary example, but it serves to illustrate the idiocy of requiring "no warnings" when the set of conditions the compiler sees fit to warn about is not under the developer's -- or customer's -- control) -- chris > > I suppose this is a rather odd question but how many warnings is too many > > when you are using a Java compiler like the one in Eclipse 3.1.1? [quoted text clipped - 30 lines] > not allow any code to be put into operations if it has even 1 warning as > a result of a compile. Which merely proves that the people in charge at DOJ are as ridiculously anal as their DoD counterparts I've worked for over the years... As another respondent has indicated, some warnings *may* be acceptable, depending on their cause. SignatureSteve W. Jackson Montgomery, Alabama >> I suppose this is a rather odd question but how many warnings is too many >> when you are using a Java compiler like the one in Eclipse 3.1.1? [quoted text clipped - 30 lines] > not allow any code to be put into operations if it has even 1 warning as > a result of a compile. thats the problem with the government just not consistent. it should be 3 counts and your out. In my java projects, which are large and highly interdependent, I turn on all warnings. The only warning I have not yet turned on are: 1. Usage of non-externalized strings 2. Serializable class without serialVersionUID 3. Boxing and unboxing conversions 4. Missing @Overrride @Deprecated annotations 5. Not all enum constants covered on 'switch' As time permits, I will turn on all. I have found many logic errors and latent bugs from the warning messages (that would have been off by default). It just makes for better code. > I suppose this is a rather odd question but how many warnings is too many > when you are using a Java compiler like the one in Eclipse 3.1.1? [quoted text clipped - 26 lines] > should never tolerate and which I should feel free to ignore without making > me look like a bad coder? > In my java projects, which are large and highly interdependent, I turn > on all warnings. The only warning I have not yet turned on are: [quoted text clipped - 6 lines] > latent bugs from the warning messages (that would have been off by > default). It just makes for better code. That's the problem. It doesn't always make for better code. Here are just a couple examples: - The reasonable reader assumes that when a class contains a field called serialVersionUID, it's going to be serialized. Yet you can accidentally inherit the Serializable interface from all manner of places (by creating any custom AWT/Swing component, for example). If the class doesn't intend to be serialized, adding a serialVersionUID is worse than useless; it's confusing. - Access to private members of an enclosing class is a language feature that's used in powerful ways. Avoiding this just because Eclipse has the option to give a warning is passing up an opportunity to write cleaner code that keeps local things local. You end up being forced to break encapsulation so that your anonymous inner classes can do useful work. Again, worse than useless. The language rule that permits this access was written deliberately with the realization that object interactions don't always correspond to abstraction boundaries, and you're taking a step back by ignoring that important fact. - Boxing conversions, as well, are a language feature that's added for a reason. Sure there are gotchas there, but why anyone should aspire to be prevented from using boxing in a Java 1.5 project escapes me. Are we actively trying to make code hard to read? It makes very little sense to assume that the people who developed Eclipse somehow know better than anyone else what's bad for code. Many of their warnings are useful (for example, you ought to immeidately enable #4 and #5, IMO), but some are not. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >- The reasonable reader assumes that when a class contains a field >called serialVersionUID, it's going to be serialized. Yet you can >accidentally inherit the Serializable interface from all manner of >places (by creating any custom AWT/Swing component, for example). If >the class doesn't intend to be serialized, adding a serialVersionUID is >worse than useless; it's confusing. On the other hand, if you inherit Serialized, are you not obligated to continue to support serialisation? Is there some convention to use to make sure your clients don't try? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On the other hand, if you inherit Serialized, are you not obligated to > continue to support serialisation? Is there some convention to use to > make sure your clients don't try? You are certainly contractually obligated to make serialization work in a well-defined manner. However, you're perfectly welcome to document that Serialization will not be compatible across releases, which is the problem that serialVersionUID solves. For example, Swing documents that restriction in all component classes (which inherit Serializable from java.awt.Component). However, if you do add a serialVersionUID, then you are VERY strongly obligated to make sure that serialization does work across releases of the class, because attempting to do so will no longer automatically fail. Adding that field means taking on a huge responsibility, and who wants Eclipse deciding for them that the responsibility is necessary? Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >> On the other hand, if you inherit Serialized, are you not obligated >> to continue to support serialisation? Is there some convention to [quoted text clipped - 13 lines] > responsibility, and who wants Eclipse deciding for them that the > responsibility is necessary? Hrm. I think this must mean there's something wrong with the whole idea of serialVersionUID. I have a bunch of classes that extend JPanels and an assortment of other JComponents. They're not intended to be serialized. They're not intended to be used as an API. There is no good reason for anyone to be serializing them, or to be extending them and then griping that they aren't serializable. It's one thing if you're writing an API, even for internal use. But when you're just writing an app? Come on! Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html Monique, There's no need to extend JPanel or JComponent. Most extensions are just a way of saving typing (as in keypresses). The one that *looks* like it's valid is overriding paintComponent for custom drawing, but even that can be better done using an Icon and, usually, a JLabel. If your class isn't supposed to be Serializable, but extends a class that is, then you have a logic error. You are subclassing something you shouldn't. It's like buying a car and then complaining when someone asks for a lift. Oh yeah, that happens.. > There's no need to extend JPanel or JComponent. Most extensions are > just a way of saving typing (as in keypresses). The one that *looks* > like it's valid is overriding paintComponent for custom drawing, but > even that can be better done using an Icon and, usually, a JLabel. I don't like extending classes where it isn't necessary. For normal uses there is no point extending JPanel. But banning a component extending JComponent is absurd. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ Thomas, > For normal uses > there is no point extending JPanel. But banning a component extending > JComponent is absurd. To my eyes, the main difference between JPanel and JComponent is that JPanel is opaque by default. I might have missed something. So I will read your text as if you said JPanel twice and omitted JComponent.. What you say is true only if abnormal uses are justified. What are these abnormal uses? > Thomas, > [quoted text clipped - 8 lines] > What you say is true only if abnormal uses are justified. What are > these abnormal uses? There's a difference of intent that matters. JPanel is intended to be used as a container for other components, and not contain a lot of logic of its own. I'm certain that's what Thomas meant. No point in extending when you're just going to add children... but there is a point in extending if you're implementing a true custom component. The fact that custom components sometimes extend JPanel, or that JComponent is technically a container, is irrelevant. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > Thomas, > [quoted text clipped - 4 lines] > To my eyes, the main difference between JPanel and JComponent is that > JPanel is opaque by default. I might have missed something. So I will You are apparently not alone in missing something. JPanel is not guaranteed to be opaque by default. It is PL&F dependent. For my machine the PL&F that matches the common native look & feel may or may not set JPanels to opaque depending upon which version of Java I use. http://java.sun.com/docs/books/tutorial/uiswing/components/toplevel.html#contentpane Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >> There's no need to extend JPanel or JComponent. Most extensions >> are just a way of saving typing (as in keypresses). The one that [quoted text clipped - 7 lines] > > Tom Hawtin I can't get Ricky's post for some reason (news server must be burping), but anyway, I'm working on a pretty complicated graphing app right now, and I really don't think it would make sense to do anything other than paint. Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html > Monique, > [quoted text clipped - 9 lines] > It's like buying a car and then complaining when someone asks for a > lift. Oh yeah, that happens.. This idea of not subclassing Swing components flies in the face of the OO paradigm. If I'm going to have a JPanel with a series of other components on it that will be used in multiple locations across my application, then the very idea of NOT creating a subclass of JPanel for that purpose is telling me to do it the hard way numerous times. = Steve = SignatureSteve W. Jackson Montgomery, Alabama > This idea of not subclassing Swing components flies in the face of the > OO paradigm. If I'm going to have a JPanel with a series of other > components on it that will be used in multiple locations across my > application, then the very idea of NOT creating a subclass of JPanel for > that purpose is telling me to do it the hard way numerous times. Not necessarily. You are welcome to write a method that builds and returns this JPanel. You don't have to do it twice. Of course, subclassing does give you extra options; i.e., it's far easier to write a template method in a superclass than to pass in a callback to a factory method. But the mere desire to avoid writing the same code twice can't justify inheritance relationships. Fortunately, OO design tends to just "make sense" after a certain amount of practice. After you've practiced creating reusable clusters of components without subclassing, it becomes obvious when subclassing is necessary (or, as in the case of using Icon for custim components from earlier this thread, avoiding it is too kludgy to be worthwhile). Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >> This idea of not subclassing Swing components flies in the face of >> the OO paradigm. If I'm going to have a JPanel with a series of [quoted text clipped - 10 lines] > callback to a factory method. But the mere desire to avoid writing > the same code twice can't justify inheritance relationships. What about a desire for readability? Inheritance from JPanel immediately gives another developer an idea of the intent of the class. And a callback to a factory method in this case sounds suspiciously like obfuscation. > Fortunately, OO design tends to just "make sense" after a certain > amount of practice. After you've practiced creating reusable > clusters of components without subclassing, it becomes obvious when > subclassing is necessary (or, as in the case of using Icon for > custim components from earlier this thread, avoiding it is too > kludgy to be worthwhile). As I may have said before, my current project involves an enormous amount of drawing, and I really do need to deal with painting. Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html When I see that a class inherits from another, I start looking for overridden methods. If I don't find any, I wonder why it inherits at all. I think public static JPanel createRoutingTablePanel() expresses intent equally as well as: final class RoutingTablePanel extends JPanel. I'm not sure why you would need a callback to a factory method, or what that exactly is. ;) Subclassing JPanel just to add some buttons to it seems to me to be akin to renaming a car whenever you add something new, e.g., electric windows. Oh yeah, car manufacturers do that.. Do you subclass String when you want to only hold addresses in it? No. You can't. Sun actually made String final, apparently for implementation reasons. I'm very glad they did. class Address extends String { } As opposed to: class Address { private final String data; } The way you are forced to do it means that you can't accidentally treat your Address as a String. Subclassing JPanel to make RoutingTablePanel means you could accidentally treat the RoutingTablePanel as a JPanel, i.e., removeAll and put new stuff on it, nicely confusing the RoutingTablePanel class. > When I see that a class inherits from another, I start looking for > overridden methods. If I don't find any, I wonder why it inherits at > all. Because the child class has an IS-A relationship with the parent class, and it adds methods, without changing the behaviour of the existing methods? > I think public static JPanel createRoutingTablePanel() expresses intent > equally as well as: [quoted text clipped - 3 lines] > I'm not sure why you would need a callback to a factory method, or what > that exactly is. ;) I don't know about the "callback" part, but based on the name "createRoutingTablePanel", this sounds like a factory method. > Subclassing JPanel just to add some buttons to it seems to me to be > akin to renaming a car whenever you add something new, e.g., electric > windows. Oh yeah, car manufacturers do that.. Well, there is the concept of "what are the childrens of this widget"? A "TwoButtonPanel" might have zero children, if you haven't added any buttons to that Panel, while a "JPanel with two buttons" always has at least 2 children. > Do you subclass String when you want to only hold addresses in it? No. > You can't. Sun actually made String final, apparently for [quoted text clipped - 13 lines] > The way you are forced to do it means that you can't accidentally treat > your Address as a String. class Age extends Number { /*...Other methods here...*/ public Time getExpectedTimeOfDeath() { return NOW; } } Is this really so bad? > Subclassing JPanel to make RoutingTablePanel means you could > accidentally treat the RoutingTablePanel as a JPanel, i.e., removeAll > and put new stuff on it, nicely confusing the RoutingTablePanel class. JPanel, specifically, is somewhat of a headache to subclass, because you have to make sure that every operation defined on JPanel also makes sense for your subclass (and there are so many operations!) If this is not the case, then your subclass probably does not have an IS-A relationship with JPanel. - Oliver >- Access to private members of an enclosing class is a language feature >that's used in powerful ways. Avoiding this just because Eclipse has [quoted text clipped - 5 lines] >interactions don't always correspond to abstraction boundaries, and >you're taking a step back by ignoring that important fact. An inner class without access to mother's fields and methods is just for all intents and purposes just an independent top level class. Why bother with an inner class if it has no outer references of any kind? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy Green schreef: >>- Access to private members of an enclosing class is a language feature >>that's used in powerful ways. Avoiding this just because Eclipse has [quoted text clipped - 9 lines] > for all intents and purposes just an independent top level class. Why > bother with an inner class if it has no outer references of any kind? Don´t you think it could be meaningful if the (static) inner class is semantically very connected to its enclosing class? For example, I have a class Function, which has a method getDomain, which returns an element of the public static inner class Domain. Domain is nothing but a small container class for two set variables, with appropriate getters. I could very easily make that a top level class, but it sort of seems to say something about the nature of this class that it belongs to the Function class. Function.Domain is more meaningful than just Domain. Until of course I think of other uses for the Domain class, but that seems unlikely. I´m just asking for an opinion here, not criticising. H. SignatureHendrik Maryns ================== www.lieverleven.be http://aouw.org > Don=3Ft you think it could be meaningful if the (static) inner class is > semantically very connected to its enclosing class? For example, I have [quoted text clipped - 9 lines] > > I=3Fm just asking for an opinion here, not criticising. That's quite possibly the case. When you do this, though, you're also tying the maintenance of the two together. Encapsulation just doesn't do much good within a source file, unless your source files are WAY too big. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >- Boxing conversions, as well, are a language feature that's added for a >reason. Sure there are gotchas there, but why anyone should aspire to >be prevented from using boxing in a Java 1.5 project escapes me. Are we >actively trying to make code hard to read? I think the notion here is to make people aware of the conversions. With autoboxing you could blithely be converting back and forth when you don't need to. An IDE could handle this with a bit of colour or a subtle glyph to mark the automatic conversions. I agree it is goofy to write the code out longhand. It just muddies the logic. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > I think the notion here is to make people aware of the conversions. > With autoboxing you could blithely be converting back and forth when > you don't need to. An IDE could handle this with a bit of colour or a > subtle glyph to mark the automatic conversions. I agree it is goofy > to write the code out longhand. It just muddies the logic. If that's the point, they needed to add a feature to the syntax highlighter. I agree that that could be helpful (presuming that they have the good sense to make it optional). Adding a warning is NOT appropriate for making people aware of this. Warnings are issued and listed for the entire project (or even workspace); they should only contain information that is important to anyone who looks at ANY part of the project. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > Can anyone give me guidelines to help me determine just what warnings I > should never tolerate and which I should feel free to ignore without making > me look like a bad coder? Prior to Java 1.5, I would have been kept up at night by warnings in pretty much anything. As of Java 1.5, it's unfortunately become a necessity that warnings exist because of type erasure with generics -- it's really not possible to do many things with generics without warnings. Nevertheless, I try hard to minimize them. I do, though, turn some potential warnings off in Eclipse. This includes things that just don't matter to me most of the time (for example, missing serialVersionUID in a Serializable class); things that aren't even potentially problematic and are in fact documented and widely used features (accessing private members of enclosing types; declaring an unnecessary checked exception); and specialized "Eclipse- isms" (non-externalized strings). Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > I suppose this is a rather odd question but how many warnings is too many > when you are using a Java compiler like the one in Eclipse 3.1.1? I believe that many people's impressions of compiler warnings are conditioned by their experience (not necessarily direct) with C and its compilers. There, the only safety comes from reading compiler "warnings", understanding them, and taking them seriously (if not necessarily changing the code). That is to say, they warn of potential errors -- a language with a different philosophy would treat them as actual errors. Java is not like that; unless the compiler can convince itself that (within certain limits) the code is OK, it will refuse to compile it. The "warnings" don't alert you to cases where it is unable to do those checks (e.g. "Waning: line 44: array indexing operation, bounds not checked" ) but where some programmer has decided that "his" idea of what good code looks like is better informed than "yours". I don't -- particularly -- object to the compiler issuing warnings (in fact there are a number of cases where I wish it would warn more), but it seems to me that some people display an overly respectful attitude to compiler warnings. That said, I don't like my code to issue any warnings either. But that's because (a) I have a tidy mind ("Extremism, officer, is the sign of a tidy mind" -- some movie) and (b) I don't want to have to pick out any useful warnings from a blizzard of drivel. It's unfortunate that Eclipse muddles its built-in style checker with its compiler. That compounds the snow-storm effect. I'm more likely to turn an Eclipse warning off than change my code. > To put it another way, if you were considering hiring me to write Java for > you and asked me for an example of a completed project to inspect, what [quoted text clipped - 4 lines] > the theory that fixing every conceivable minor warning is not required to > prove that you write good code. Am I close? Taking this perhaps more literally than you meant. I wouldn't care much about the number of warnings which showed up with his/her code in /my/ environment. The two questions I'd want answered would be: Are /any/ of the warnings evidence that the candidate does not understand Java ? And, as a question to put directly to the candidate: if their environment showed no warnings): How do you decide which warnings to turn off ? or if their environment showed any warnings (which I would take as a negative point anyway -- I like a tidy mind): How can you tell that there's nothing important in that list ? -- chris I turn on most of the Eclipse warnings, but also have a separate CheckStyle configuration, which I invoke every so often from ant. It does a frankly pedantic series of checks, which would get in the way of the 30 or so persistent warnings about serialisation UIDs and deprecated API usages that I'm slowly removing. I'm removing the serialisation UID warnings simply by not subclassing. When I've no warnings left in Eclipse I might make Eclipse use my CheckStyle configuration to display warnings all the time. I find less than 50 warnings workable - otherwise it's difficult to see new warnings. I don't think Eclipse keeps a log of when the warning was first thrown up by the build. Rhino schreef: > I suppose this is a rather odd question but how many warnings is too many > when you are using a Java compiler like the one in Eclipse 3.1.1? I use warnings as a TODO marker for more serious things: if there is no javadoc for a method, that means the method is not ok. But I suppose that´s not really a good idea. I have turned on a lot of warnings, and got rid of them, from time to time using @SuppressWarnings, if I really need to clone an ArrayList, for example. OTOH, I could do return new ArrayList<Something>(oldArrayList), but I don´t really like that. Then, if you think you can use even more warnings, have a look at PMD: http://pmd.sourceforge.net/. Fortunately, you can have those warnings in a separate view in Eclipse. H. SignatureHendrik Maryns ================== www.lieverleven.be http://aouw.org > I suppose this is a rather odd question but how many warnings is too many > when you are using a Java compiler like the one in Eclipse 3.1.1? For me, even one warning showing up in production code is too many. I try to eliminate them during development, but one might survive a day or two during creation. Thus, I only activate warnings I am willing to eliminate. Our teams have a policy of mandatory and optional warnings. By this, we mean that we have agreed on a set of warning messages that we will eliminate when we get them. There is a much larger set that we suggest programmers turn on, and eliminate as they get the chance. This way, as code evolves, different people turn on different warnings to eliminate them, and once we all feel that the code is 'pretty good', we move a warning from the optional to the mandatory list. > Using the default settings for the 1.5 compiler in a fresh install of > Eclipse 3.1.1, my various projects have over 4000 messages between them, 22 [quoted text clipped - 4 lines] > 'error' or 'warning'. And, of course, I could probably make the vast > majority of them go away simply by rewriting code. This is typical. We saw much the same when we started using IDEA and Eclipse. We turned off most of them, turned on a few that we thought valuable, and have added one or two a month since. Most of us using IDEA have had a larger set that we would routinely turn on and fix the code, but that was a target of opportunity. > To put it another way, if you were considering hiring me to write Java for > you and asked me for an example of a completed project to inspect, what [quoted text clipped - 4 lines] > that fixing every conceivable minor warning is not required to prove that > you write good code. Am I close? Pretty close - for IDEA, I would suggest spending an afternoon reading all of the possible warnings, then deciding which ones make sense for your style. You can then use that as a matter of discussion during an interview. For example, many of the 'optimization' ones are a bit dodgy, while the threading and 'data members not private' ones have caught problems for us. Thus, if your code threw warnings with my set, I would want to know why. A response like 'I see no real benefit in replacing a one character string with an actual character, as both are equally expressive of programmer intent.' might well fly with me, even though I usually have that warning on. Scott SignatureScott Ellsworth scott@alodar.nospam.com Java and database consulting for the life sciences >I suppose this is a rather odd question but how many warnings is too many >when you are using a Java compiler like the one in Eclipse 3.1.1? 87. 86 is just barely passable, 85 is okay. But once you've got 87, you know you have problems. > Using the default settings for the 1.5 compiler in a fresh install of > Eclipse 3.1.1, my various projects have over 4000 messages between them, [quoted text clipped - 4 lines] > conditions to 'error' or 'warning'. And, of course, I could probably make > the vast majority of them go away simply by rewriting code. I've got 15058 warnings in my current Eclipse workspace. The settings of what are considered warnings and what aren't vary from project to project. "Externalized Strings" is turned off everywhere, I think. Some of my code is machine generated, so I can't just go in and fix the warnings. I have to change the code-generator so that the code it generates no longer generates warnings. Except the code-generator itself is generated, so I can't directly edit that either. That's my excuse for having 15058 warnings. When I'm programming at home, for fun, none of my code is generated, and there's probably 0 warnings right now, though it occasionally does reach the single non-zero digit range. And I try to turn all the warnings on, except sometimes I get lazy, and turn "externalized strings" off. The only time I use "@SuppressWarning" is for those "impossible to avoid" situations with generics, and I accompany the annotations with a comment explaining why I believe that the warning is unavoidable. Unfortunately, @SuppressWarning seems to work on a whole method, instead of on a particular warning, so I occasionally have to remove them to make sure I didn't introduce new warnings without my realizing it. > I'd be surprised if anyone turned _all_ conditions to 'warning' or 'error' > and then fixed every single one of the warnings and errors so that the > entire workspace was error-free but maybe I'm wrong. That's why I'd like > some feedback on just how many errors and warnings is considered okay and > what is considered excessive. Surprise! > To put it another way, if you were considering hiring me to write Java for > you and asked me for an example of a completed project to inspect, what [quoted text clipped - 4 lines] > the theory that fixing every conceivable minor warning is not required to > prove that you write good code. Am I close? For what it's worth, when I got this job, they never asked me anything about my philosophy on warnings. On the other hand, they did give me a (simple) programming problem and asked me to solve it, so they got to see what kind of code I wrote. Maybe they combed it for warnings, maybe they didn't. At any rate, the code I gave them had zero warnings with the default warning/error/ignore settings they had on the workstation they were testing me on. Also, errors should almost always be zero, as the javac compiler will refuse to compile code with errors. Eclipse seems to be able to compile code with errors (I believe it just replaces the erroneus block with boilerplate code which just throws an exception), so it's conceivable there might be shops out there who are willing to tolerate errors in an Eclipse environment. Also, when you're compilation tools, sometimes things that one tool (e.g. javac) considers an error is not to be considerd an error by another tool (e.g. your inhouse compiler), so there are cases there where errors might be okay too. > Can anyone give me guidelines to help me determine just what warnings I > should never tolerate and which I should feel free to ignore without > making me look like a bad coder? I think "number of warnings" is not where you should focus your concern. For every setting in Eclipse, do you understand what the warning associated with it means? Could you explain it to another programmer? - Oliver Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.