> Same with shadowed variables, a truly horrible idea. I look at code > and see an inst var, but fail to notice it is also an argument or > method var and I'm off being confused about what the code does.
I never heard of a JavaScript, Java, C, C++, Ruby, Python, or Scheme programmer complain about shadowed variables. It makes sense to refer to a variable closest in scope shadowing those with the same name farther away. > or we should have a tool that point us to the shadowing. :) Code Critics already does that today. > If you allow abuse of the language, people will do it. Of course. That's why we have thisContext, #perform:, #become:, #nextInstance, #isKindOf:, #instVarAt:, etc. That's why we have Code Critics that reminds people to be careful about these things. That's also the reason why there is Seaside. And that's why there is no Seaside for Java. >> Same for upper/lowercase conventions, let alone uppercase method >> names. >> >> Breaking the kind of conventions makes you think harder about what >> code does and that distracts you from what you really trying to do. Or >> should be doing ;-) I like the metaphor of global being uppercase and local being lowercase. I don't see a point enforcing that though: The meaning of global and local is rather arbitrary. In the context of the subclasses of a class all instance variables are global. In the context of a method the method arguments are global as well. There is a big difference between syntax and coding conventions: 1. Syntax: This is what the compiler can compile unambiguous. This is the syntax as found in the back of the Smalltalk-80 book. This is the grammar that deterministically decides if a program can be compiled or not. For portability it should follow the ANSI standard as close as possible. Note that the ANSI standard does not restrict names of globals, classes, inst-vars, class inst-vars, class-vars, pools, methods, temps, ... in any way: they are all identifiers, starting with an upper or lowercase letter, followed by zero or more letters or digits. If it is decided to restrict these names, Pharo won't be ANSI compatible anymore. 2. Coding Conventions: This is what the community decides to follow and what every serious open source project should publish somewhere on the web. This includes rules like "temps and instance variables are lowercase" or "code is formatted with tabs and there are no empty lines". For Seaside we have such rules and we rigorously reject/rewrite code that does not follow these guidelines, see <http://www.seaside.st/community/conventions>. We use Code Critics to detect violations against these rules or to automatically fix poroblems. This ensures a high quality of the core code, but still enables other parties to write and use code that does not follow these conventions. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
