All languages must err on the side of excess. They must let you put together features in ways that encourage or cause bugs. For example, C++ is evil because it lets you write many statements on one line, preventing readability.

So all programmers must err on the side of caution. They must only type statements known to work the way they expect them to; production code should not explore the dark corners of the language.

SaneSubset means using a subset of the language features, not the generative possibilities. You have to do that anyway because there are an infinite number of expressions possible in most languages.

SaneSubset''''''s differ from BadStyleGuides; the former are intrinsic features of a language, learned by coding in it, and the latter are imposed without technical foundations.

----

Example:

Don't define the body of a friend member function inside another class that befriends it:


	class
	ClassB {
	 void FunctionB (); // no body
	 ...
	};

	class
	ClassA {
	 friend void ClassB::FunctionB () { ... }
	 ...
	};

FunctionB is ''not'' a member of ClassA, but its body is inside the definition of ClassA. Don't do this to your colleagues - there is simply no technical reason to.

This example differs from placing a free function inside a befriending class.

----

I can't think of any feature of Eiffel or Smalltalk which does not belong to the sane subset.

''Some peoples' "sane subset" of Eiffel would exclude taking away methods in subclasses, e.g Emu subclassing Bird and removing the fly() method.''

[Covariant argument types ought to be out of the SaneSubset as well]

Some people, yes. C++ is unusual in that the author of the language himself seems to advise against using certain features.

''All languages must err on the side of excess. Languages which do not err on the side of excess are called "BondageAndDisciplineLanguage''''''s". Their SaneSubset is imposed upon you by the languages' authors. The only thing worse than BadStyleGuides imposed by an employer are those imposed by a language author. -- PhlIp''


In Smalltalk, I would consider changing the classes of True and False to switch the semantics of ifTrue and ifFalse to be outside the sane subset.

[In Smalltalk, an explicit return from a code block that outlives the referencing environment in which it is created is often considered a no-no. ''It will cause a runtime error ("Attempt to return twice" or something similar)'']


-----

Some language features exist only for compatibility with previous versions. It's generally a good idea to use their more up-to-date replacements. For example: use "static const" variables in C++ instead of #define, where possible. ''(Don't you mean 'anonymous namespaces'? ;-)''

As for strict standards of what subset to use... I find that good programmers will use only language, library and system features that directly contribute to successful implementation of the system they're developing. One never uses a cool new feature (in a production program) just to try it out, or just because it's there. Therefore, good programmers will always end up using a small subset of the language 99% of the time, and will only use advanced features of the language (multiple inheritance and partial specialization of templates, for example) when needed. Thus, I would generally be '''against restricting your team to a strictly defined subset of a language''' or library -- unless you think they're irresponsible.
''(In which case, why don't you fire them and hire competent help?  ;-)'' -- JeffGrigg


Okay, that's odd. I won't claim necessarily that I'm a "good programmer", but I ''often'' use a cool new feature "just to try it out". I prefer to do so on a small program than a major project (or test it first on a prototype, THEN use it on the big project), but I do this a lot, and intentionally. I find that it keeps me abreast of the field, and learning new things. A good example would be that as soon as they added GeneratorsInPython, I arranged some scripts so they used them. It probably wasn't the best design every time, but without experimenting, how would I ever learn? And "learn on your own time, not your boss's" won't work for me: my learning takes more of my time and effort than that. -- MichaelChermside