C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  having the compiler enforce "good programming style" Goto page 1, 2, 3, 4, 5, 6, 7, 8  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Michael Jørgensen Guest Posted: Thu Mar 17, 2005 9:49 pm    Post subject: having the compiler enforce "good programming style" Hi, Here is an idea I've been thinking about for a while: The idea is to have the compiler enforce "good programming style". Since there are differing views on such matters, it should be configurable in the form of a text file, and passed to the compiler as a command line parameter, i.e. something like "-style=<file>". The whole idea is to provide lint-like capability to the compiler, but also to go a step or two beyond that: When programming in C++, some constructs are legal but considered "bad practice". So, a company might want to enforce a policy that forbids, e.g. - C style casts - malloc and friends. - classes where only some of: destructor, copy constructor, and assigment operator are defined. - inconsistent indentation. - inconsistent variable naming. - missing comments. - etc. Legacy code would be compiled with a default style that makes few or no restrictions. Different companies will of course have different style files, but presumably over time the community could agree to a select few "widely adopted" styles. Ideally, such a style file will completely replace the existing coding standards, and in fact will make for consistent documentation of the local policy. Any comments, anyone? Has there been any work done along these lines? -Michael. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Pete Becker Guest Posted: Fri Mar 18, 2005 1:06 pm    Post subject: Re: having the compiler enforce "good programming style" Michael Jørgensen wrote: Quote: Here is an idea I've been thinking about for a while: The idea is to have the compiler enforce "good programming style". Since there are differing views on such matters, it should be configurable in the form of a text file, and passed to the compiler as a command line parameter, i.e. something like "-style=<file>". Make sure that anything like this can be disabled. It's bad enough keeping track of what compiler writers think I can't be trusted to use correctly to implement the standard library, without adding arbitrary user conventions. -- Pete Becker Dinkumware, Ltd. (http://www.dinkumware.com) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Trevor L. Jackson, III Guest Posted: Fri Mar 18, 2005 1:13 pm    Post subject: Re: having the compiler enforce "good programming style" Michael Jørgensen wrote: Quote: Hi, Here is an idea I've been thinking about for a while: The idea is to have the compiler enforce "good programming style". Since there are differing views on such matters, it should be configurable in the form of a text file, and passed to the compiler as a command line parameter, i.e. something like "-style=<file>". The whole idea is to provide lint-like capability to the compiler, but also to go a step or two beyond that: When programming in C++, some constructs are legal but considered "bad practice". So, a company might want to enforce a policy that forbids, e.g. - C style casts - malloc and friends. - classes where only some of: destructor, copy constructor, and assigment operator are defined. - inconsistent indentation. - inconsistent variable naming. - missing comments. - etc. Legacy code would be compiled with a default style that makes few or no restrictions. Different companies will of course have different style files, but presumably over time the community could agree to a select few "widely adopted" styles. Ideally, such a style file will completely replace the existing coding standards, and in fact will make for consistent documentation of the local policy. Any comments, anyone? Has there been any work done along these lines? A sizable fraction of the "features" of C++ are aimed at that goal. Things like the inability to pass a temporary object to a non-const reference have nothing to do with the expressive power of the language and everything to do with attempting to prevent programmers from making mistakes. IMHO the entire effort is itself a mistake. One cannot make tools safer without making them less capable -- in some cases much less capable. /tj3 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Carlos Moreno Guest Posted: Sat Mar 19, 2005 10:46 am    Post subject: Re: having the compiler enforce "good programming style" Trevor L. Jackson, III wrote: Quote: Any comments, anyone? Has there been any work done along these lines? A sizable fraction of the "features" of C++ are aimed at that goal. And a considerable fraction is limited to *facilitate* good and safe programming practices, and not to encourage them. Another considerable fraction of the features does a little bit more: it *encourages* good and safe practices. But the OP's suggestion makes sense to me -- individual companies have internal programming practices where certain practices are required and certain other practices are forbidden. Each individual entity has all the right to do as they please; they own the code their programmers do, and they are the ones that pay the programmers to code: they have the right to require their programmers to do as they want. Now, why would you oppose to a piece of software that simplifies the task of enforcing whatever programming practices they want? You (or I) are no-one to tell them what features they should use and what they shouldn't. Quote: IMHO the entire effort is itself a mistake. One cannot make tools safer without making them less capable -- in some cases much less capable. The thing is, less capable of what? Less capable of screwing up? Are you unhappy because you're not capable of modifying an object that has been declared const? (well, you *are* capable, of course, but you'd have to go out of your way to do it). Do you feel that you have to be capable of writing programs that have only global variables, all with a one-letter name (two letters maximum, and only if we need more than 52 variables), and that use no functions and no classes/structs whatsoever? Carlos -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Pete Becker Guest Posted: Sun Mar 20, 2005 1:53 am    Post subject: Re: having the compiler enforce "good programming style" Carlos Moreno wrote: Quote: Now, why would you oppose to a piece of software that simplifies the task of enforcing whatever programming practices they want? Because I have to write headers that compile in the environment that someone else creates. It's hard enough to quiet warnings from six different compiler vendors' notions of "good practice" (which sometimes conflict). I can't imagine doing this for user-specifiable criteria. Is someone wants to use lint they can use lint. It's not the compiler's job. -- Pete Becker Dinkumware, Ltd. (http://www.dinkumware.com) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Trevor L. Jackson, III Guest Posted: Sun Mar 20, 2005 1:54 am    Post subject: Re: having the compiler enforce "good programming style" Carlos Moreno wrote: Quote: Trevor L. Jackson, III wrote: Any comments, anyone? Has there been any work done along these lines? A sizable fraction of the "features" of C++ are aimed at that goal. And a considerable fraction is limited to *facilitate* good and safe programming practices, and not to encourage them. Another considerable fraction of the features does a little bit more: it *encourages* good and safe practices. But the OP's suggestion makes sense to me -- individual companies have internal programming practices where certain practices are required and certain other practices are forbidden. Each individual entity has all the right to do as they please; they own the code their programmers do, and they are the ones that pay the programmers to code: they have the right to require their programmers to do as they want. Now, why would you oppose to a piece of software that simplifies the task of enforcing whatever programming practices they want? You (or I) are no-one to tell them what features they should use and what they shouldn't. IMHO the entire effort is itself a mistake. One cannot make tools safer without making them less capable -- in some cases much less capable. The thing is, less capable of what? Less capable of screwing up? Are you unhappy because you're not capable of modifying an object that has been declared const? (well, you *are* capable, of course, but you'd have to go out of your way to do it). Do you feel that you have to be capable of writing programs that have only global variables, all with a one-letter name (two letters maximum, and only if we need more than 52 variables), and that use no functions and no classes/structs whatsoever? Yes. And I do so. In assembler. When I need to write higher level software I use a higher level language. C++, in spite of its instability and logical lacunae is a good one. That's not the issue. The issue is the safety belts that get in the way of writing clear, correct code. A related issue is the interlocking of what should be orthogonal aspects of the code. Examples abound. 1.) Every translation unit is required to have at least one external definition. That requirement gets in the way of code for scaffolding, test harnesses and debugging. It gains users of the language *nothing*. Translation units should be allowed to be empty. if you cannot handle an empty translation unit, why should I believe you can handle one with source in it? 2.) Templates must have a least one parameter (this one really surprised me it is so stupid. A function template without parameters is just a function. A class template without parameters is just a class. Why doesn't C++ forbid functions without arguments? strings with no characters? functions with no statements? statements with no expressions?) The rule *creates* an unnecessary gap in the development of good templates that even the designer of the language said should begin with the design, implementation, and testing of non-templates. Empty template argument lists should be supported. If you cannot handle the zero case, why should I believe you can have the cases with one or more? [the above two make me suspect someone does not understand that zero is a legitimate number for expressing the count of elements of a linguistic feature] 3.) Changing the writability of a variable alters the default linkage of the object. This sounds like it was _designed_ to trip up programmers. It *cannot* be justified by any amount of rationalization because having a keyword silently change the default for an unrelated property is *never* a good idea. Adding or removing constness should not affect any other property of the affected entity. Specifically, it should be possibly to remove all const qualifiers from a const-correct program and have a correct program with the same semantics. That is not currently possible. 4.) Objects with const members or with reference members must have a constructor. Thus they cannot be PODs! These rules reinforce my opinion that initialization has been neglected and even damaged during the development of the standard. Objects with const or reference members should not require constructors. Failing to initialize an a const or reference member during the creation of an object should be an error. 5.) Temporary objects cannot be bound to non-const references even when it is appropriate to do so -- i.e., there is no override mechanism. A mechanism to associate references with objects of any qualification is necessary. See comment re const-correctness above. 6.) Constructors cannot call each other. This leads to very complex work-arounds with private member functions and puts member initialization in conflict with singularity of implementation. This cannot be excused as necessary. It is just another case of unnecessary inconsistency in the language. A constructor should be able to invoke a sibling constructor in exactly the same way as a constructor invokes a base class constructor. Am I bashing C++? of course not. Am I criticizing the existing standard? Damned right. But constructively. Your "defense" of the standard was _not_ constructive. Nothing I said had anything to do with writing BASIC in C++ as you suggested. So either deal with the actual issues or waste your time harassing someone else. /tj3 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top M Jared Finder Guest Posted: Sun Mar 20, 2005 2:02 am    Post subject: Re: having the compiler enforce "good programming style" Carlos Moreno wrote: Quote: Trevor L. Jackson, III wrote: IMHO the entire effort is itself a mistake. One cannot make tools safer without making them less capable -- in some cases much less capable. The thing is, less capable of what? Less capable of screwing up? Are you unhappy because you're not capable of modifying an object that has been declared const? (well, you *are* capable, of course, but you'd have to go out of your way to do it). Do you feel that you have to be capable of writing programs that have only global variables, all with a one-letter name (two letters maximum, and only if we need more than 52 variables), and that use no functions and no classes/structs whatsoever? If I encounter a problem where making all variables global is the cleanest and simplest solution, then yes, I do feel I should be capable of writing programs that have only global variables. A more realistic example would be a requirement like "never use raw pointers -- always use safe pointers". What if I encounter a problem where the cleanest solution would be to create a new type of safe pointer, and use that? I *can't* create a new type of safe pointer without using raw pointers, so I can't solve the problem. I'd be very very wary of taking away capability without providing a simple (though verbose) way of getting that power back. Look at C++'s reinterpret_cast and const_cast. They provide a way to work around the compiler's type system in unsafe ways, but they are there because they are *sometimes needed*. -- MJF [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Joshua Lehrer Guest Posted: Sun Mar 20, 2005 9:03 am    Post subject: Re: having the compiler enforce "good programming style" Are you suggesting that you think one should be able to pass a temporary by non-const reference? If something would be a mistake 99% of the time, then why not forbit it, in the language, given that there are easy workarounds for the other 1%? joshua lehrer factset research systems NYSE:FDS [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ivan Vecerina Guest Posted: Sun Mar 20, 2005 9:05 am    Post subject: Re: having the compiler enforce "good programming style" "Pete Becker" <petebecker (AT) acm (DOT) org> wrote: Quote: Now, why would you oppose to a piece of software that simplifies the task of enforcing whatever programming practices they want? Because I have to write headers that compile in the environment that someone else creates. It's hard enough to quiet warnings from six different compiler vendors' notions of "good practice" (which sometimes conflict). Just out of curiosity: could you provide examples of conflicting warnings you've had to find workarounds for? (I've only ever had to test production code on 2, maybe 3 compilers) Thank you, Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Carlos Moreno Guest Posted: Sun Mar 20, 2005 11:33 pm    Post subject: Re: having the compiler enforce "good programming style" M Jared Finder wrote: Quote: Carlos Moreno wrote: Trevor L. Jackson, III wrote: IMHO the entire effort is itself a mistake. One cannot make tools safer without making them less capable -- in some cases much less capable. The thing is, less capable of what? Less capable of screwing up? Are you unhappy because you're not capable of modifying an object that has been declared const? (well, you *are* capable, of course, but you'd have to go out of your way to do it). Do you feel that you have to be capable of writing programs that have only global variables, all with a one-letter name (two letters maximum, and only if we need more than 52 variables), and that use no functions and no classes/structs whatsoever? If I encounter a problem where making all variables global is the cleanest and simplest solution, then yes, I do feel I should be capable of writing programs that have only global variables. Hmmm, no, sorry, this argument is, IMHO, too weak... The *if* is too hypothetical and too unrealistic. But ok, we can still accept this argument (see below), even though you kind of admit it yourself that it is a bit unrealistic. Quote: A more realistic example would be a requirement like "never use raw pointers -- always use safe pointers". What if I encounter a problem where the cleanest solution would be to create a new type of safe pointer, and use that? I *can't* create a new type of safe pointer without using raw pointers, so I can't solve the problem. I'd be very very wary of taking away capability without providing a simple (though verbose) way of getting that power back. Look at C++'s reinterpret_cast and const_cast. They provide a way to work around the compiler's type system in unsafe ways, but they are there because they are *sometimes needed*. Yes, I agree. And this does not contradict what the OP was suggesting (at least not the way I interpreted it). You can always play with the configuration file, or use a special configuration file for a particular source file in which you have a good case to make an exception to the rules that you established as a general policy. Carlos -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Carlos Moreno Guest Posted: Sun Mar 20, 2005 11:35 pm    Post subject: Re: having the compiler enforce "good programming style" Pete Becker wrote: Quote: Carlos Moreno wrote: Now, why would you oppose to a piece of software that simplifies the task of enforcing whatever programming practices they want? Because I have to write headers that compile in the environment that someone else creates. It's hard enough to quiet warnings from six different compiler vendors' notions of "good practice" (which sometimes conflict). I can't imagine doing this for user-specifiable criteria. I don't see this as an argument against such system; I see it more like a reason why the compiler should disable all those validations whenever it includes a standard library file (ok, perhaps it would be a tough job for the compiler to keep track of that, but still). Now, I'm not familiar with this lint -- if it is an external software that does that job, then ok; I'm kind of defending the idea that the OP suggested, regardless of whether it's the compiler or some other piece of software that executes it. (and of course, provided that standard library headers are excluded from such validation process) Carlos -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Carlos Moreno Guest Posted: Sun Mar 20, 2005 11:36 pm    Post subject: Re: having the compiler enforce "good programming style" Trevor L. Jackson, III wrote: Quote: Your "defense" of the standard was _not_ constructive. Who was defending the standard? Are you sure you're not confusing me with someone else? Quote: Nothing I said had anything to do with writing BASIC in C++ as you suggested. But what the OP was suggesting does -- I was using the "writing BASIC in C++" as an example to defend what the OP was proposing, and contradict/contest your statement that suggests that any restriction in how you write code decreases the useability and the power of the language. As a general rule, yes, things tend to go more or less correlated this way. But the language does allow you to write BASIC in C++; if someone gives me a tool *that I can configure to* allow me to prevent such code to be written, I wouldn't complain; I wouldn't feel that the power of the language has been crippled. Now, if that tool always prevents me from using global variables at all, then I would complain -- but the key element here is something that was suggested by the OP: *configurability*. You specify, perhaps through a configuration file, what set of features you want to enforce. My point keeps being: if I'm an employer, and I pay you (as an example) for writing C++ code for me, I have all the right to *order* you not to use a single global variable; and I do it, by manually inspecting your code... Why opposing to a software tool that would allow me to do it without having to manually inspect the code? If you have a good case for using one global variable in a very particular situation, you would come in my office to try to convince me, right? If you have a good case, you might convince me and I would allow you to do it that one time without firing you () -- same thing if we have the tool; if you have a good case and convince me, then I would turn off that feature in the configuration file of that hypothetical system to accomodate for your global variable that you convinced me was a sound idea. Carlos -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Pete Becker Guest Posted: Sun Mar 20, 2005 11:37 pm    Post subject: Re: having the compiler enforce "good programming style" Ivan Vecerina wrote: Quote: Just out of curiosity: could you provide examples of conflicting warnings you've had to find workarounds for? That was a bit of shorthand; sometimes rewriting code to eliminate a warning from one compiler doesn't eliminate a similar warning from another compiler, and you end up spending still more time finding a way to rewrite legal, unambiguous, well-defined code in a way that makes both compilers happy. I'm rarely rational on this subject. It is a pain in the *** to have to write to the intersection of various random notions of what constitutes "good programming style." -- Pete Becker Dinkumware, Ltd. (http://www.dinkumware.com) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Trevor L. Jackson, III Guest Posted: Sun Mar 20, 2005 11:39 pm    Post subject: Re: having the compiler enforce "good programming style" Joshua Lehrer wrote: Quote: Are you suggesting that you think one should be able to pass a temporary by non-const reference? I'm pretty sure I said so. If I did not say so previously, there I hereby say so. Of course it is a dangerous practice and should not be used routinely. But when it is necessary it is necessary and the implementation should not presume to dictate that it cannot be necessry. I would not mind and would postively appreciate a warning/error diagnostic as the usual case. But just as there are rare occasions in which a goto or a cast is the proper solution to a problem, sometimes a non-const reference argument needs to receive a temporatry argument. Note that that last sentence distinguishes a specific case from the general case of initializing references. The specific case is not categorically wrong whereas the gmore general case of loose references initialized with temporary objects is incorrect in almost every case. But the simplistic rule against binding a temporary to a non-const reference is defective because it does not make the fine distinctions required to improve the language. The crudeness of the rule results in a net decrease int he utility of the language. And it is unnecessary because C++ is never going to be a "safe" language in which to write code. Not ever. Quote: If something would be a mistake 99% of the time, then why not forbit it, in the language, given that there are easy workarounds for the other 1%? Because I should not have to work around the language's "features". it is in exactly those tricky or strange cases that clarity of code becomes paramount. Contrived code is usually the symptom of bad design. In these cases the defective design is not in the application, but in the language itself. There are lots of things that are bad programming practice that are not and should not be forbidden. Any other approach is inconsistent with the premise that the final responsibility for hte software lies with the programmer rather than with the compiler. If you want to design languages for use by people who don't know better then go enhance Visual BASIC and leave the languages intended to be used by people who do know better alone. The last thing C++ programmers need is restrictions on their expressive power "for their own good". /tj3 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jonathan Turkanis Guest Posted: Sun Mar 20, 2005 11:52 pm    Post subject: Re: having the compiler enforce "good programming style" Ivan Vecerina wrote: Quote: "Pete Becker" <petebecker (AT) acm (DOT) org> wrote: Now, why would you oppose to a piece of software that simplifies the task of enforcing whatever programming practices they want? Because I have to write headers that compile in the environment that someone else creates. It's hard enough to quiet warnings from six different compiler vendors' notions of "good practice" (which sometimes conflict). Just out of curiosity: could you provide examples of conflicting warnings you've had to find workarounds for? (I've only ever had to test production code on 2, maybe 3 compilers) How about: - function must return a value - statement is unreachable ? Jonathan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2, 3, 4, 5, 6, 7, 8  Next Page 1 of 8   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.