Re: Google C++ style guide
== Quote from Don (nos...@nospam.com)'s article
> Jeremie Pelletier wrote:
> > Christopher Wright wrote:
> >> Jeremie Pelletier wrote:
> >>> Me neither, in fact I would *love* to see a -nrtti switch in DMD to
> >>> disable the generation of all ClassInfo and TypeInfo instances, along
> >>> with a version identifier, maybe "version = RTTI_Disabled;" to let
> >>> code handle it.
> >>>
> >>> I use RTTI a lot for simple debugging like printing the name of a
> >>> class or type in generic code or meta programming, but not at all in
> >>> production code. Most of the time I can rely on .stringof and a
> >>> message pragma to do the same.
> >>
> >> You use RTTI for dynamic casts, variadic functions, and the default
> >> implementation of toString. You could safely eliminate some fields
> >> from ClassInfo and TypeInfo, but you can't get rid of them entirely.
> >>
> >> The best you can do is make TypeInfo entirely opaque (no fields) and
> >> only include the base class, interfaces, and name for ClassInfo.
> >
> > Yeah something like "don't generate type names" and other extra
> > informations would be a definive plus, that makes reverse engineering
> > too easy :)
> I've often thought that a pragma for a module to "don't generate module
> info" would be very useful for executable size. I'm particularly
> thinking of bindings like the Win32 headers, where there are a hundred
> modules, and the module info isn't actually useful. There could be a
> default ModuleInfo instance, with module name "ModuleInfoUnavailable",
> which all such modules would point to.
One thing that can trip this up is structs containing floating point numbers
or static arrays, since they have custom initializers. I've taken to declaring
structs from C headers with an "= void" to eliminate the link dependency,
but maybe the initializer could be eliminated by declaring the struct as:
struct S
{
char c = 0;
float[2] f = 0.0[];
}
Or something like that.
Re: Google C++ style guide
>If you want me to list something that's a little evil, is the automatic silent
>cast from an integral to its unsigned version. I'd like to disallow such
>silent cast in D (maybe C# does the same).<
We may even disallow all implicit conversions that lose a significant amount of
information:
double => float
real => float
(I think C# requires such casts).
And maybe even (but this is less handy, so I am not sure): real => double
Even long => real sometimes loses a little information:
import std.stdio: writeln;
void main() {
real r = long.min;
writeln(r, " ", cast(long)r, " ", long.max-cast(long)r);
}
But for now I'm not interested in regulating long => real implicit casts.
Bye,
bearophile
Re: Google C++ style guide
Jeremie Pelletier wrote: bearophile wrote: Don: I've often thought that a pragma for a module to "don't generate module info" would be very useful for executable size. Do you use the LDC compiler? LDC has the pragmas: pragma(no_typeinfo): You can use this pragma to stop typeinfo from being implicitly generated for a declaration. pragma(no_moduleinfo): You can use this pragma to stop moduleinfo from being implicitly generated for a declaration. Sounds great. They should be standard. I've never used those yet, I'll try them soon. But you meant something more global, module-wide. Maybe you can ask to LDC devs. I agree that having standard and not compiler-specific features is better. Bye, bearophile I would much prefer these to be compiler switches, so you can make them global with very little effort. That's a completely different use case, I think. For internal modules, the existence of that module is an implementation detail, and shouldn't be externally visible even through reflection, IMHO.
Re: Google C++ style guide
Jeremie Pelletier: > However we're > talking systems programming here, people want the choice between using > the feature or not using it :) We aren't talking about a feature here, but a standard syntax to denote class attributes. And D being a system language has nothing to do with being free to take such kind of choices. A system language has to give freedom in how you use memory or how you use the CPU at runtime, it has nothing to do to the syntax you use to write identifiers. Such freedom isn't required. Bye, bearophile
Re: Google C++ style guide
Kagamin: > > I'm for the removal of size_t from everywhere it's not stricly necessary > > (so for example from array lenghts) to avoid bugs. > > Yess, unsigneds are evil. They must go to the camp of gotos and unsafe > pointers. In D it's better to not use them when you want a strictly positive number, or for general iteration purposes, etc. So I don't like to see them used in the built-ins and std lib where they aren't necessary. I use them when I need bitfields, or when I need the full range (but that's less common). If you want me to list something that's a little evil, is the automatic silent cast from an integral to its unsigned version. I'd like to disallow such silent cast in D (maybe C# does the same). Walter may answer on this. Regarding pointers, they are unsafe, but there are ways to increase their safety a little, with no performance costs in release mode. I think this is positive because it helps find and fix bugs in less time. Bye, bearophile
Re: Google C++ style guide
Jeremie Pelletier: > I would much prefer these to be compiler switches, so you can make them > global with very little effort. Compiler switches are a blunt tool. So I think module-wide switches are better. Bye, bearophile
Re: Google C++ style guide
bearophile wrote: Don: I've often thought that a pragma for a module to "don't generate module info" would be very useful for executable size. Do you use the LDC compiler? LDC has the pragmas: pragma(no_typeinfo): You can use this pragma to stop typeinfo from being implicitly generated for a declaration. pragma(no_moduleinfo): You can use this pragma to stop moduleinfo from being implicitly generated for a declaration. I've never used those yet, I'll try them soon. But you meant something more global, module-wide. Maybe you can ask to LDC devs. I agree that having standard and not compiler-specific features is better. Bye, bearophile I would much prefer these to be compiler switches, so you can make them global with very little effort.
Re: Google C++ style guide
Kagamin Wrote: > In fact DMD has bug here: spec says, this pointer must not be taken > implicitly or explicitly, yet dmd allows calling virtual methods on the > object being constructed. A... I've misread the spec a little. Though I think, it's still a problem that constructor allows to call virtual methods.
Re: Google C++ style guide
bearophile Wrote: > >Function Parameter Ordering: When defining a function, parameter order is: > >inputs, then outputs.< > > D may even enforce this, allowing "out" only after "in" arguments. I'm trying to do the reverse. Maybe I used fprintf and sprintf too much. > >Static and Global Variables: Static or global variables of class type are > >forbidden: they cause hard-to-find bugs due to indeterminate order of > >construction and destruction. [...] The order in which class constructors, > >destructors, and initializers for static variables are called is only > >partially specified in C++ and can even change from build to build, which > >can cause bugs that are difficult to find. [...] As a result we only allow > >static variables to contain POD data.< > > I think D avoids such problem. No. D has static constructors which do the same. > >Doing Work in Constructors: Do only trivial initialization in a constructor. > >If at all possible, use an Init() method for non-trivial initialization. > >[...] If the work calls virtual functions, these calls will not get > >dispatched to the subclass implementations. Future modification to your > >class can quietly introduce this problem even if your class is not currently > >subclassed, causing much confusion.< > Never understood this advice to split the construction of object? What is it trying to solve? And how they plan to not dispatch calls to subclasses? Do they overwrite vtbl at the end of constructor? In fact DMD has bug here: spec says, this pointer must not be taken implicitly or explicitly, yet dmd allows calling virtual methods on the object being constructed. > >Declaration Order: Use the specified order of declarations within a class: > >public: before private:, methods before data members (variables), etc.< > > D may even enforce such order (Pascal does something similar). Methods before data seems unnatural for me. > >Decision: If you want to overload a function, consider qualifying the name > >with some information about the arguments, e.g., AppendString(), AppendInt() > >rather than just Append().< > > > This is a strong limitation. One of the things that makes C++ more handy than > C. I accept it for normal code, but I refuse it for "library code". Library > code is designed to be more flexible and reusable, making syntax simpler, etc. > So I want D to keep overloaded functions. A good example is BinaryWriter. It's unusable when implemented with overloaded methods. > >Default Arguments: We do not allow default function parameters.< > > >Decision: We require all arguments to be explicitly specified, to force > >programmers to consider the API and the values they are passing for each > >argument rather than silently accepting defaults they may not be aware of.< > Is it a solution? Default parameters can be emulated by overloads with different number of parameters, which call actual method with defaults for the rest of the parameters. They just propose to always use the full api? How about going back to asm to consider your code rather than accepting compiler magic? > Integer Types: > > >You should not use the unsigned integer types such as uint32_t, unless the > >quantity you are representing is really a bit pattern rather than a number, > >or unless you need defined twos-complement overflow. In particular, do not > >use unsigned types to say a number will never be negative. Instead, use > >assertions for this.< > > I'm for the removal of size_t from everywhere it's not stricly necessary (so > for example from array lenghts) to avoid bugs. Yess, unsigneds are evil. They must go to the camp of gotos and unsafe pointers. > Type Names: often I don't like the C++ practice of using a single uppercase > letter for a template type, like T. Better to give a meaningful name to > types, when possible. > I thought it's a common practice that the length (meaningfulness) of the name of a variable is determined more by the size of its scope rather than its purpose. > >Spaces vs. Tabs: Use only spaces, and indent 2 spaces at a time.< > > 4 spaces are more readable :-) > I prefer 3. 4 is too much. Almost every editor has the option to specify the tab width and people have different tastes.
Re: Google C++ style guide
Don: > I've often thought that a pragma for a module to "don't generate module > info" would be very useful for executable size. Do you use the LDC compiler? LDC has the pragmas: pragma(no_typeinfo): You can use this pragma to stop typeinfo from being implicitly generated for a declaration. pragma(no_moduleinfo): You can use this pragma to stop moduleinfo from being implicitly generated for a declaration. I've never used those yet, I'll try them soon. But you meant something more global, module-wide. Maybe you can ask to LDC devs. I agree that having standard and not compiler-specific features is better. Bye, bearophile
Re: Google C++ style guide
Jeremie Pelletier wrote: Christopher Wright wrote: Jeremie Pelletier wrote: Me neither, in fact I would *love* to see a -nrtti switch in DMD to disable the generation of all ClassInfo and TypeInfo instances, along with a version identifier, maybe "version = RTTI_Disabled;" to let code handle it. I use RTTI a lot for simple debugging like printing the name of a class or type in generic code or meta programming, but not at all in production code. Most of the time I can rely on .stringof and a message pragma to do the same. You use RTTI for dynamic casts, variadic functions, and the default implementation of toString. You could safely eliminate some fields from ClassInfo and TypeInfo, but you can't get rid of them entirely. The best you can do is make TypeInfo entirely opaque (no fields) and only include the base class, interfaces, and name for ClassInfo. Yeah something like "don't generate type names" and other extra informations would be a definive plus, that makes reverse engineering too easy :) I've often thought that a pragma for a module to "don't generate module info" would be very useful for executable size. I'm particularly thinking of bindings like the Win32 headers, where there are a hundred modules, and the module info isn't actually useful. There could be a default ModuleInfo instance, with module name "ModuleInfoUnavailable", which all such modules would point to.
Re: Google C++ style guide
Justin Johansson: > The return type must be specified however, > since inference cannot be made from missing information. If the information isn't missing in D2 you can sometimes use "auto" return type for function templates and some functions, and in some other situations you can also use typeof(return). Bye, bearophile
Re: Google C++ style guide
Jérôme M. Berger Wrote:
> bearophile wrote:
> > I have found this page linked from Reddit (click "Toggle all summaries" at
> > the top to read the full page):
> > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
> >
> > At Google C++ isn't the most used language, so it may be better to use a
> > C++ style guide from a firm that uses C++ more than Google. On the other
> > hand Google has hired many good programmers, and probably some of them have
> > strong C++ experience, so if you are interested in C++/D this style guide
> > deserves to be read.
> >
> > This guide is mostly (as it often happens with C++) a list of features that
> > are forbidden, I think usually to reduce the total bug count of the
> > programs. Some of such imposed limits make me a little nervous, so I'd like
> > to remove/relax some of those limits, but I am ignorant regarding C++,
> > while the people that have written this document are expert, so their
> > judgement has weight.
> >
> > They forbid several features that are present in D too. Does it means D has
> > to drop such features (or make them less "natural", so the syntax
> > discourages their use)?
> >
> > Here are few things from that document that I think are somehow
> > interesting. Some of those things may be added to D style guide, or they
> > may even suggest changes in the language itself.
> >
> > ---
> >
> >> Function Parameter Ordering: When defining a function, parameter order is:
> >> inputs, then outputs.<
> >
> > D may even enforce this, allowing "out" only after "in" arguments.
> >
> I actually use the inverse convention: "out" arguments come first.
> This way, it is easy to see that "a = b" and "assign (a, b)" modify
> "a" and not "b".
>
> Jerome
Ditto. A special use case to consider is when you have a function template
that returns a type
that is a template parameter and the types of the function arguments are also
template parameters.
Often type inference can be used to determine the type of the function
arguments without explicit
qualification of the argument types in the instantiation. The return type must
be specified however,
since inference cannot be made from missing information.
This suggests a natural order that results (and out arguments) should be on the
LHS and (in) arguments
on the RHS.
So if one writes this:
R Foo(R, A1, A2)( A1 arg1, A2 arg2) {
R r;
return r;
}
auto r = Foo!(double)( 3, 4);
Isn't it more natural or consistent to write this also:
void Bar(R, A1, A2)( out R r, A1 arg1, A2 arg2) {
}
double r;
Bar!(double)( 3, 4);
I haven't tried it so not sure if this works but you get the idea.
Another reason why outs/inouts should be before in arguments is in the case of
functions
taking variable length argument lists or variadic arguments. Normally there is
only one
output argument but there is an arbitrary number of input arguments that the
function
can take.
Yet another reason why so is by analogy with output stream functions; an output
stream
argument is analogous to an output value or reference.
Nearly all I/O libraries that I've seen have usage like this:
fprintf( stdout, /+args...+/);
write( os, value);
Rarely the other way around, namely, input arguments before output stream/file
channel argument.
-- Justin Johansson
Re: Google C++ style guide
bearophile wrote: I have found this page linked from Reddit (click "Toggle all summaries" at the top to read the full page): http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml At Google C++ isn't the most used language, so it may be better to use a C++ style guide from a firm that uses C++ more than Google. On the other hand Google has hired many good programmers, and probably some of them have strong C++ experience, so if you are interested in C++/D this style guide deserves to be read. This guide is mostly (as it often happens with C++) a list of features that are forbidden, I think usually to reduce the total bug count of the programs. Some of such imposed limits make me a little nervous, so I'd like to remove/relax some of those limits, but I am ignorant regarding C++, while the people that have written this document are expert, so their judgement has weight. They forbid several features that are present in D too. Does it means D has to drop such features (or make them less "natural", so the syntax discourages their use)? Here are few things from that document that I think are somehow interesting. Some of those things may be added to D style guide, or they may even suggest changes in the language itself. --- Function Parameter Ordering: When defining a function, parameter order is: inputs, then outputs.< D may even enforce this, allowing "out" only after "in" arguments. I actually use the inverse convention: "out" arguments come first. This way, it is easy to see that "a = b" and "assign (a, b)" modify "a" and not "b". Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Google C++ style guide
Christopher Wright wrote: Jeremie Pelletier wrote: Me neither, in fact I would *love* to see a -nrtti switch in DMD to disable the generation of all ClassInfo and TypeInfo instances, along with a version identifier, maybe "version = RTTI_Disabled;" to let code handle it. I use RTTI a lot for simple debugging like printing the name of a class or type in generic code or meta programming, but not at all in production code. Most of the time I can rely on .stringof and a message pragma to do the same. You use RTTI for dynamic casts, variadic functions, and the default implementation of toString. You could safely eliminate some fields from ClassInfo and TypeInfo, but you can't get rid of them entirely. The best you can do is make TypeInfo entirely opaque (no fields) and only include the base class, interfaces, and name for ClassInfo. Yeah something like "don't generate type names" and other extra informations would be a definive plus, that makes reverse engineering too easy :)
Re: Google C++ style guide
> >Function Parameter Ordering: When defining a function, parameter order is:
inputs, then outputs.<
> D may even enforce this, allowing "out" only after "in" arguments.
> ---
Function Default Arguments
void foo(int x, int y = 3)
{
...
}
...
foo(4); // same as foo(4, 3)
Re: Google C++ style guide
Jeremie Pelletier wrote: Me neither, in fact I would *love* to see a -nrtti switch in DMD to disable the generation of all ClassInfo and TypeInfo instances, along with a version identifier, maybe "version = RTTI_Disabled;" to let code handle it. I use RTTI a lot for simple debugging like printing the name of a class or type in generic code or meta programming, but not at all in production code. Most of the time I can rely on .stringof and a message pragma to do the same. You use RTTI for dynamic casts, variadic functions, and the default implementation of toString. You could safely eliminate some fields from ClassInfo and TypeInfo, but you can't get rid of them entirely. The best you can do is make TypeInfo entirely opaque (no fields) and only include the base class, interfaces, and name for ClassInfo.
Re: Google C++ style guide
bearophile wrote: Jeremie Pelletier: I think these are more programming guidelines than language design rules.< Yes, of course. But programming guidelines can give possible ideas to a language designer, because: - if everyone is encouraged to follow a certain idiom to avoid bugs, it may be good to let the language itself enforce the idiom (see D that disallows for(...); ). - if most similar guidelines suggest to not use a certain language feature, such feature may need a redesign, or maybe to be made "less nice" syntax-wise, so the syntax shows its usage is discouraged. - if in many guidelines suggest to do something in a standard way, to improve uniformity, it may be good to add such thing too to help spreading and transmission of code in the programmer community of that language. One of the causes of Python success is that it forces a very uniform coding style, and this helps people understand and modify each other code, this helps a little the creation of an ecosystem of reusable code. The compile-enforcing of syntax for class attributes in D can be one of such things. I'm not sure if that's a good thing, different companies enforce different guidelines for different reasons, and then you have independent programmers with their own guidelines too. As for less nice syntax, I'd hate to use __goto, __traits is already ugly enough that I always hide it behind a template with a nicer name and lets not even talk about __gshared showing its ugly self all over my C bindings :) Maybe if the compiler had a -strict switch to enforce a certain guideline over code, we already have -safe for enforcements over memory usage! Such an enforcement would then be an awesome feature for D to have. I'm not against the idea, I'm against making it the only available option! I was talking about smarter function, that allocates on the heap if the requested size is too much large or if the stack is finishing :-) But of course fixed sized arrays are often enough. Those smarts have some overhead to them to first check the allocation size and the remaining stack size, and finally call the appropriate allocator, that overhead would almost make such a smart function useless when compared to direct heap allocations. D template programming can become very unreadable, trust me :-) Not anymore than any other bit of code :) Sometimes I avoid "i" for loops :-) Sometimes I avoid "T" for templates :) Here I don't agree with you. Uniformity in such thing is important enough. Again I believe such an enforcement should be behind a -strict switch, I agree with you that uniformity can be a great thing and I can only imagine the all good it does to the python community. However we're talking systems programming here, people want the choice between using the feature or not using it :) Jeremie
Re: Google C++ style guide
Jeremie Pelletier: >I think these are more programming guidelines than language design rules.< Yes, of course. But programming guidelines can give possible ideas to a language designer, because: - if everyone is encouraged to follow a certain idiom to avoid bugs, it may be good to let the language itself enforce the idiom (see D that disallows for(...); ). - if most similar guidelines suggest to not use a certain language feature, such feature may need a redesign, or maybe to be made "less nice" syntax-wise, so the syntax shows its usage is discouraged. - if in many guidelines suggest to do something in a standard way, to improve uniformity, it may be good to add such thing too to help spreading and transmission of code in the programmer community of that language. One of the causes of Python success is that it forces a very uniform coding style, and this helps people understand and modify each other code, this helps a little the creation of an ecosystem of reusable code. The compile-enforcing of syntax for class attributes in D can be one of such things. >enforcing parameter order would also break lots of existing code.< D2 is in flux still, every release breaks existing code. >I don't recall C having a "ref" keyword :)< Sorry, I meant C# (CSharp). >I completely agree here, JavaScript for example has no default parameters and >it's annoying as hell. Looking at existing code is really handy to learn about >the usage of a function when the documentation is too vague, that >documentation is still the best source to learn about the parameters.< I'm waiting for named arguments too in D :-) >I barely use alloca at all, since you don't always know if the array is going >to be 50 bytes or 20k bytes. If you know the array's size or at least the max >size it can get then you can just use a fixed-size array which will get >allocated on the stack.< I was talking about smarter function, that allocates on the heap if the requested size is too much large or if the stack is finishing :-) But of course fixed sized arrays are often enough. >I don't think this guideline was about the size of integrals but rather their >sign bit.< Right, I meant unsigned integral numbers. >Yeah I would like overflow tests in D too, although I don't like how you can't >control which tests are used and which arent, they're either all enabled or >all disabled.< There are ways to solve this problem/limit. Putting basic tests in is a starting point. I have given LLVM developers some small enhancements requests to implement such tests more efficiently: http://llvm.org/bugs/show_bug.cgi?id=4916 http://llvm.org/bugs/show_bug.cgi?id=4917 http://llvm.org/bugs/show_bug.cgi?id=4918 I have also discussed this topic with LDC developers, for possible implementations. >I agree it can get very hard to maintain readability in C++, but D does not >have that problem. Templates in D are very elegant and much more powerful than >C++'s at the same time.< D template programming can become very unreadable, trust me :-) >I think T fits generic template parameters the same way i fits for loops :)< Sometimes I avoid "i" for loops :-) >I don't think it should be enforced by the language, it's a great guideline >but the programmer should be free to select its flavor (ie m_var, mVar, _var, >var_, etc)< Here I don't agree with you. Uniformity in such thing is important enough. Bye and thank you for your answers, bearophile
Re: Google C++ style guide
bearophile wrote: I have found this page linked from Reddit (click "Toggle all summaries" at the top to read the full page): http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml At Google C++ isn't the most used language, so it may be better to use a C++ style guide from a firm that uses C++ more than Google. On the other hand Google has hired many good programmers, and probably some of them have strong C++ experience, so if you are interested in C++/D this style guide deserves to be read. This guide is mostly (as it often happens with C++) a list of features that are forbidden, I think usually to reduce the total bug count of the programs. Some of such imposed limits make me a little nervous, so I'd like to remove/relax some of those limits, but I am ignorant regarding C++, while the people that have written this document are expert, so their judgement has weight. They forbid several features that are present in D too. Does it means D has to drop such features (or make them less "natural", so the syntax discourages their use)? Here are few things from that document that I think are somehow interesting. Some of those things may be added to D style guide, or they may even suggest changes in the language itself. I think these are more programming guidelines than language design rules. That's like most academic teachers saying "goto" is evil and should never be used, yet new languages like D still support it. --- Function Parameter Ordering: When defining a function, parameter order is: inputs, then outputs.< D may even enforce this, allowing "out" only after "in" arguments. That can be good for readability in most cases, but I also like to order parameters in logical order instead of storage class order, enforcing parameter order would also break lots of existing code. Static and Global Variables: Static or global variables of class type are forbidden: they cause hard-to-find bugs due to indeterminate order of construction and destruction. [...] The order in which class constructors, destructors, and initializers for static variables are called is only partially specified in C++ and can even change from build to build, which can cause bugs that are difficult to find. [...] As a result we only allow static variables to contain POD data.< I think D avoids such problem. Indeed, static ctors/dtors are very useful but I like to keep their number down to a minimum and perform lazy initialization instead. --- Declaration Order: Use the specified order of declarations within a class: public: before private:, methods before data members (variables), etc.< D may even enforce such order (Pascal does something similar). Again, I wouldn't want to enforce such an order, sometimes I declare a private helper method right next to the set of public methods using it so I don't have to scroll down 400 lines to view the two. --- Reference Arguments: All parameters passed by reference must be labeled const.< In fact it is a very strong convention in Google code that input arguments are values or const references while output arguments are pointers. Input parameters may be const pointers, but we never allow non-const reference parameters.< I think C solves part of such problem forcing the programmer to add "ref" before the variable name in the calling place too. D may do the same. I don't recall C having a "ref" keyword :) That guideline I agree with, that's also how I write my parameters, although I take it a step further in D with in/const/immutable: 'in' for variables that are not modified and don't escape the method's scope. 'const' for variables that are not modified but escape the method's scope, maybe with a copy because the data may be mutable somewhere else. 'immutable' for variables that are not modified but escape the method's scope, never copied because they're expected to never change for their entire lifetime. --- Function Overloading: Use overloaded functions (including constructors) only in cases where input can be specified in different types that contain the same information. Cons: One reason to minimize function overloading is that overloading can make it hard to tell which function is being called at a particular call site. Another one is that most people are confused by the semantics of inheritance if a deriving class overrides only some of the variants of a function.< Decision: If you want to overload a function, consider qualifying the name with some information about the arguments, e.g., AppendString(), AppendInt() rather than just Append().< This is a strong limitation. One of the things that makes C++ more handy than C. I accept it for normal code, but I refuse it for "library code". Library code is designed to be more flexible and reusable, making syntax simpler, etc. So I want D to keep overloaded functions. I partly agree, fun
Re: Google C++ style guide
bearophile Wrote: > >Regular Functions: Functions should start with a capital letter and have a > >capital letter for each new word. No underscores:< > > That's ugly. Coming from a career in acronym-city (aerospace), project management mandated that use of acronyms in identifiers MUST be clearly indicated with uppercase letters. In the event that ambiguity could arise, such as in camel-cased identifiers, the end of an acronym had to be separated by an underscore between it and any following letter in the identifier. This rule, whilst painful/ugly at times, was rigorously enforced in safety critical systems lest there be any possibility, no matter how remote, of confusion with interpretation of nomenclature in systems engineering documents. So, for example, the following were for verboten: ParseXmlDocument(The correct acronym for Xml is XML) PaseXMLDocument (XMLD might be erroneously interpreted as a 4 letter acronym) Required formulation of the identifier in the case must be "ParseXML_Document". Ciao Justin Johansson
Google C++ style guide
I have found this page linked from Reddit (click "Toggle all summaries" at the top to read the full page): http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml At Google C++ isn't the most used language, so it may be better to use a C++ style guide from a firm that uses C++ more than Google. On the other hand Google has hired many good programmers, and probably some of them have strong C++ experience, so if you are interested in C++/D this style guide deserves to be read. This guide is mostly (as it often happens with C++) a list of features that are forbidden, I think usually to reduce the total bug count of the programs. Some of such imposed limits make me a little nervous, so I'd like to remove/relax some of those limits, but I am ignorant regarding C++, while the people that have written this document are expert, so their judgement has weight. They forbid several features that are present in D too. Does it means D has to drop such features (or make them less "natural", so the syntax discourages their use)? Here are few things from that document that I think are somehow interesting. Some of those things may be added to D style guide, or they may even suggest changes in the language itself. --- >Function Parameter Ordering: When defining a function, parameter order is: >inputs, then outputs.< D may even enforce this, allowing "out" only after "in" arguments. --- >Nested Classes: Do not make nested classes public unless they are actually >part of the interface, e.g., a class that holds a set of options for some >method.< --- >Static and Global Variables: Static or global variables of class type are >forbidden: they cause hard-to-find bugs due to indeterminate order of >construction and destruction. [...] The order in which class constructors, >destructors, and initializers for static variables are called is only >partially specified in C++ and can even change from build to build, which can >cause bugs that are difficult to find. [...] As a result we only allow static >variables to contain POD data.< I think D avoids such problem. --- >Doing Work in Constructors: Do only trivial initialization in a constructor. >If at all possible, use an Init() method for non-trivial initialization. [...] >If the work calls virtual functions, these calls will not get dispatched to >the subclass implementations. Future modification to your class can quietly >introduce this problem even if your class is not currently subclassed, causing >much confusion.< --- >Declaration Order: Use the specified order of declarations within a class: >public: before private:, methods before data members (variables), etc.< D may even enforce such order (Pascal does something similar). --- >Reference Arguments: All parameters passed by reference must be labeled const.< >In fact it is a very strong convention in Google code that input arguments are >values or const references while output arguments are pointers. Input >parameters may be const pointers, but we never allow non-const reference >parameters.< I think C solves part of such problem forcing the programmer to add "ref" before the variable name in the calling place too. D may do the same. --- Function Overloading: Use overloaded functions (including constructors) only in cases where input can be specified in different types that contain the same information. >Cons: One reason to minimize function overloading is that overloading can make >it hard to tell which function is being called at a particular call site. >Another one is that most people are confused by the semantics of inheritance >if a deriving class overrides only some of the variants of a function.< >Decision: If you want to overload a function, consider qualifying the name >with some information about the arguments, e.g., AppendString(), AppendInt() >rather than just Append().< This is a strong limitation. One of the things that makes C++ more handy than C. I accept it for normal code, but I refuse it for "library code". Library code is designed to be more flexible and reusable, making syntax simpler, etc. So I want D to keep overloaded functions. --- >Default Arguments: We do not allow default function parameters.< >Cons: People often figure out how to use an API by looking at existing code >that uses it. Default parameters are more difficult to maintain because >copy-and-paste from previous code may not reveal all the parameters. >Copy-and-pasting of code segments can cause major problems when the default >arguments are not appropriate for the new code.< >Decision: We require all arguments to be explicitly specified, to force >programmers to consider the API and the values they are passing for each >argument rather than silently accepting defaults they may not be aware of.< This too is a strong limitation. I und
