Many programmers and database admins seem to prefix their variables or table names with a few letters to indicate the type of the entity. For example, for some reason unknown to me, most of the databases I have come across have "tbl" prefixed to every table name, and even worse I've seen "fld" (for field) prefixed to every column!
In a time where every database has a set of GUI tools to view them, which conveniently groups tables, views, stored procedures with their own icons... what benefit does this naming bring? To me it only seems to bring problems, I'll give you an example.
Where I work we inherited a set of legacy databases to build a new web application on top of, the old website needed to continue to function. We decided to reorganize the databases to make them easier to maintain. To remain backwards compatible with the legacy website, we created views to the actual tables to mimic the old design. Here is the problem, the views are now named "tblXYZ" instead of "vwXYZ", an annoyance, making the already pointless prefix naming, now down right counter intuitive. The only way to change this situation is to go back and change all the code that accesses the table and rename the views. A long, and potentially bug inducing process.
It's even worse with variable naming, if at some point down the line, you decide that your intVariable needs to become a fltVariable you need to go through an rename every occurrence of the damn thing, what advantage does that naming bring in either statically or dynamically typed languages?
Don't prefix names based on types. By all means prefix to prevent name clashes (member variable vs local variable) but prefixing based on a type is more hassle than its worth.
Friday, 14 August 2009
Thursday, 6 August 2009
Am I just patching over the cracks?
So, my last blog post got a fair bit more notice than I intended. I actually didn't think anybody read this blog except my Twitter/Facebook/IM contacts so I was totally (surprised|amazed|horrified) to find the post on the front page of Reddit and posted to wine-devel and on numerous Linux and Open Source websites. On reflection, I did write that post in a particularly bad mood so perhaps the wording could have come across slightly more inflammatory than intended. Still, on the sites I visited, I only saw one comment that proclaimed I was an idiot, many comments of the "OK, perhaps the Wine the process isn't quite perfect" nature and some saying they enjoyed my writing... I should post in a bad mood more often! Some good has actually come from my post in the form of this wiki page, which I think is a great idea!
Anyway, in the post I stated I am going to write a web-app to display patches that may have fallen into the black hole; rejected with or without feedback and then never resubmitted. I've started it, it's more tricky than I thought (matching patches is going to be a headache) but as soon as it's ready I'll post a link here.
However, I've been thinking that maybe I'm tackling this back-to-front and looking at the comments, others seem to agree.
At work, we use Redmine as our issue tracker. It is, just pure awesome. It's like Trac but better, it allows for multiple "trackers" so, bug trackers, feature trackers, support trackers and.. you guessed it PATCH TRACKERS! It also supports GIT integration, news posting, milestones/roadmap, multiple projects, wikis and forums. Wait a second, that's ALL the stuff that Wine needs!!
Wine uses Bugzilla as its bug tracker, something else for its wiki, patches are sent via mailing lists, milestones are kept track of by Bugzilla tags, and the forum is another piece of software. But if it was all integrated that would be really cool, in a bug report you can link directly to a file under version control, you can link to a revision where the bug was fixed and see the change, you can link between the wiki, the tracker issues and the VCS. Emails could be sent to wine-patches when a patch is submitted through the patch tracker. Also with the ability to plan an actual roadmap of releases the frequency of stable releases could be increased.
Obviously, migrating everything would be a massive undertaking and, it probably wouldn't be the best way to go. The Wine devs rely on mailing lists to do their day-to-day work, so any move to something like Redmine would need to be able to keep with their workflow. Like I said, the patch tracker could be configured to send emails to wine-patches... but I don't know if someone's reply to the email can make it back into the tracker. Also the wine-users forum integrates with the mailing list, and the Redmine Wiki does seem more limited than Wine's current one. Sigh.
I guess if Wine was to start from a completely clean slate, then Redmine might be the way to go, but as that's not the case maybe the devs could take a step back and cherry-pick ideas from other combined bug trackers to more greatly unify their tools. I know integrating logins between all the tools is quite a high priority. Perhaps a patch tracker (e.g. a bugzilla for patches) which integrates with wine-patches should be the next step, maybe instead of retrospectively trying to find the code that has been lost, I should instead be focusing on preventing future patches going missing? Perhaps, there should be an all encompassing super tool which combines patch tracking and patchwatcher? Who knows?
Anyway, in the post I stated I am going to write a web-app to display patches that may have fallen into the black hole; rejected with or without feedback and then never resubmitted. I've started it, it's more tricky than I thought (matching patches is going to be a headache) but as soon as it's ready I'll post a link here.
However, I've been thinking that maybe I'm tackling this back-to-front and looking at the comments, others seem to agree.
At work, we use Redmine as our issue tracker. It is, just pure awesome. It's like Trac but better, it allows for multiple "trackers" so, bug trackers, feature trackers, support trackers and.. you guessed it PATCH TRACKERS! It also supports GIT integration, news posting, milestones/roadmap, multiple projects, wikis and forums. Wait a second, that's ALL the stuff that Wine needs!!
Wine uses Bugzilla as its bug tracker, something else for its wiki, patches are sent via mailing lists, milestones are kept track of by Bugzilla tags, and the forum is another piece of software. But if it was all integrated that would be really cool, in a bug report you can link directly to a file under version control, you can link to a revision where the bug was fixed and see the change, you can link between the wiki, the tracker issues and the VCS. Emails could be sent to wine-patches when a patch is submitted through the patch tracker. Also with the ability to plan an actual roadmap of releases the frequency of stable releases could be increased.
Obviously, migrating everything would be a massive undertaking and, it probably wouldn't be the best way to go. The Wine devs rely on mailing lists to do their day-to-day work, so any move to something like Redmine would need to be able to keep with their workflow. Like I said, the patch tracker could be configured to send emails to wine-patches... but I don't know if someone's reply to the email can make it back into the tracker. Also the wine-users forum integrates with the mailing list, and the Redmine Wiki does seem more limited than Wine's current one. Sigh.
I guess if Wine was to start from a completely clean slate, then Redmine might be the way to go, but as that's not the case maybe the devs could take a step back and cherry-pick ideas from other combined bug trackers to more greatly unify their tools. I know integrating logins between all the tools is quite a high priority. Perhaps a patch tracker (e.g. a bugzilla for patches) which integrates with wine-patches should be the next step, maybe instead of retrospectively trying to find the code that has been lost, I should instead be focusing on preventing future patches going missing? Perhaps, there should be an all encompassing super tool which combines patch tracking and patchwatcher? Who knows?
Subscribe to:
Posts (Atom)