The Myth that “Features” must be used…

March 25, 2007 on 12:56 am | In .NET Coding |

I’ve been doing a lot of research reading and experimentaion lately in the field of compiler writing and language theory, and I keep running across a lot of miscellaneous blog entries or responding comments that make assertions somewhere on the order of “But since we’re using c# we should be using properties for everything that can possibly have them, because otherwise, what is c# for?” In essense they’re suggesting that “since you can use properties, then you should.” I don’t get it… other than default applicability in databinding and XmlSerialization (sometimes these things aren’t needed, believe it or not!) In my estimation, properties, when you don’t have access to the source code can be ambiguous as to whether or not they are just setters or getters… And Fields, well if you aren’t executing code on them, and aren’t firing events when they are modified, then it’s perfectly acceptable to use just plain old public fields! Call me a heretic or something… but you can always change a field to a property later, and without taking away the usability of it.

There are very good reasons for using properties though, like implementing interfaces, but lets not forget that methods can go in interfaces too! So what’s wrong with having a method called get_Name() and another set_Name()? (Ignoring the fact that properties are effectively methods anyway,) I think that’s perfectly clear what they do in that case, and the only possible drawback is the fact that they don’t get recognized as first class units of state by the XmlSerializer and databinders. I don’t think it’s very likely that my Lexer is going to need to be serialized, and the same goes for my Compiler class…

There is a time and a place for every tool, and indeed the features of that tool, including c#’s properties, but they aren’t required just because they exist, lets not be ridiculous.

This brings me round to another point I like to make… it’s not correct for someone to assert users of any one particular programming language are of any higher or lesser degree ‘real programmers.’ I like C the best myself, but C# seems to let me do a lot of what I need, and in a windows environment, I can get around with it pretty nicely. I would also posit to you the reader that even VB6 can be used as a good tool, and even by REAL programmers. Computer Scientists who are actually devotees to the field know that once you learn your first 5 or 6 languages, the rest are easy! That being said, since you know six or seven languages, and most of the time more than that, as a computer scientist or a programmer, it’s up to you to pick the language that suits your familiarity and the environment you’re coding for, in the best way. It’s wholly possible to intermingle some C# classes with some vb.net for a corporate website project… but do you think being stubborn in the use of C# over VB.net is actually producing anything of value, especially when the maintainer of the overall project two years from know will be primarily comparing your code to that of 4 or 5 other VB.net programmers who started on the project before you got there? There will be a definite gear switch involved in even trying to debug the code you’re writing. I’m not a purist advocate of any one language, and I think it’s ridiculous to hear (and I have heard) for example a Java programmer tell me that they would not use parameterized queries against the database because they were ‘Java Programmers not SQL programmers.’
Perhaps I’m biased on this issue, because I love everything about coding. I like the syntax, I like learning new, old, archaic, and esoteric languages, and I even like writing them. I very much enjoy .net on windows, as well as some lower level C hacking (and even nasm — but only once) on a linux box. Scripting? Sure! Everything from ksh to vbscript! It’s all in the name of being resourceful and applying tools from whatever toolbox you find most useful in solving a particular problem. A programmer is someone who engineers a solution to a problem that adequately makes use of the available resources, one of which is TIME, and I’m not just talking about execution time. Development time is the most expensive bit of writing code, especially when using truely arbitrary conventions. (This is NOT a reference to dependency injection which actually can be quite productive as a methodology. I’m merely jabbing at those who like to say “I’m a(n) X language developer not a Y language kiddie!”)

Wow, I rant a lot. Sorry about that. (I’m only saying that to be polite.)

Let me finish this up with something constructive and point to the site from which I have grabbed the most useful information on programming languages:

http://lambda-the-ultimate.org/

It’s affectionately known by many as LtU. So far, for me, it really is the ultimate.

EDIT: Ok I thought of one more good reason where you would want to make sure that your classes use properties and not fields… If you intend to allow derived classes to override your top level behavior. But, for sealed or Static classes though … you get the idea