Naming conventions that suck

I've been using C# for while now but I've spent most of my career to date using java in enterprise development. The naming conventions for java, the official ones from Sun that is, seem to be mostly logical and there is a well defined getter/setter access naming for beans that fits nicely I especially like that boolean member variables have a getter preceded by 'is' because it makes sense.

There is, or at least doesn't appear to be the same level of common sense with C# instead there seems to be a clinging on to the past. At least most people no longer put sz at the front of zero terminated strings or i in front of integers like back in the C/C++ days which lets face it were quite some time ago and things have moved on so get over it.

When I see code where interfaces are preceded by 'I' or member variables that are prefixed with '_' it makes the code look childish, it's what I'd expect an old school programmer/hacker from yester-year who has refused to expand their own understanding would do.

In the days of C the naming conventions were there because there were no clever IDE's so the quickest way to convey to the user what a variable was was to include something in the name which were generally kept short (I don't know but there may have been a limit on variable name length). The fact the conventions such as 'I' for interfaces and '_' for member variables is retained in a language that lets you define a variable as 'var' and let the compiler infer the type smacks of hypocrisy and those that follow it are simply refusing to grow beyond their limit understanding.

I for one am looking forward to the day that variable names contain spaces as the norm like they can in Groovy because it makes sense to be able to convey simply what the purpose for a variable is as it no longer matters how many characters are used in the name so be expressive.

A strange convention that I started using then found to be wonderful for allowing me to scan read code was to put a space after the opening parenthesis and a space before the closing parenthesis, it sounds odd but the little box that the parameters are now in really can be easy to spot whereas you can't quickly scan down code where there is no space because it seems harder for the brain (mine at least) to see the fact that the parameters are separate from the method name.

Just remembered another stupid convention used in C#, capital letters for methods and capital letters for properties. This seems like an opportunity missed since methods are usually verbs they'd fit nicely in the middle of a sentence whereas properties tend to be concepts or nouns that are more likely to be names therefore why not lowercase for methods and upper case for properties. Ok, so it's not that stupid I just prefer lower case methods as capital letters tend to stop the flow of my brain due to decades of teaching it that a full stop followed by a capital letter signifies the end of a section that the author deemed worthy of signifying.

Machines that learn

I wanted to design a machine that learns, always have ever since I saw wargames with Matthew Broderick. Trouble is it ain't easy. Humans are very good at seeing patterns and I wondered if this has anything to do with the ability to learn. Maybe if we see patterns we're able to apply previous experience to similar situations. On another note I was thinking that a tree of decisions where each node is itself a tree creating thing. This would tie in with the idea of CNN where there is a bias feedback loop between nodes. Ok so I am starting to like the idea that each node in a tree is itself a tree creating thinking machine, I like the idea that all this tree has knowledge of is what ever is below it i.e. its children and its childrens children e.t.c.