I don't, you were speaking about more typing :). Let's screw it, I am not going to troll here. My only reason was I don't like senetences with like "DON'T" and "NEVER". It is bad practice, but velociraptor won't attack you.
2010/11/26 Jamie Fraser <[email protected]> > It is more typing, because it breaks intellisense (in SSMS 2008, for > example). I don't often type table names in Visual Studio, but again, it > breaks intellisense there too. At least it is consistent. > > I'm not sure why you mention duck typing, as we're speaking specifically > about database tables being prefixed "tbl". Language indifferent. You do > not, and should not, prefix them with "tbl". > > Not sure what you mean by "your "more typing"". I have never equated more > typing with good / bad practice. Redundant table qualifiers are bad. Don't > try and put words into my mouth. > > > > > On Fri, Nov 26, 2010 at 4:23 PM, Processor Devil < > [email protected]> wrote: > >> Here is a nice link about programmer's practices: http://xkcd.com/292/ >> >> Now seriously: >> 1) More typing? Everything anyone does in visual studio is to type few >> letters and then smash enter or few arrows down and enter. >> 2) I doubt you spend status meetings reading your code aloud (and tbl >> would be read as table) >> 3) Try to code in Boo or IronPython where you use duck-typing by default. >> As I have said I used to tibble (mainly because of Python was my former >> programming language of choice). >> There was also time I used recursive goto in one of my C programs just >> because I wanted to run the code in loop. >> Goto is publicly considered as a bad practice, but according to your "more >> typing" I guess it's right because I saved me from typing more lines of code >> :). >> >> 2010/11/26 Jamie Fraser <[email protected]> >> >>> Its bad practice and should be avoided, which is why I said it. Its >>> completely redundant, offers no benefit whatsoever, and makes lots of things >>> more difficult. Intellisense gets broken, every table requires extra typing, >>> talking about tables with other devs/BA/testers requires mental rephrasing. >>> >>> There are lots of things which won't crash your computer, but it >>> certainly doesn't mean you should be doing them. I hope you don't use >>> "doesn't crash my machine" as justification for poor programming practices. >>> There is enough terrible source code and system architecture out there >>> without adding to it. >>> >>> >>> On Fri, Nov 26, 2010 at 4:14 PM, Processor Devil < >>> [email protected]> wrote: >>> >>>> Yes, Customers and tblCustomers is really the same thing. So where is >>>> the problem in using it? :). >>>> There is a choice you can make. My original post wasn't about >>>> right/wrong, I just don't like if someone says "NEVER DO >>>> THIS!!!!1111eleven". It won't crash your computer and the Earth won't >>>> explode. >>>> >>>> 2010/11/26 Stephen Russell <[email protected]> >>>> >>>> On Fri, Nov 26, 2010 at 9:52 AM, Processor Devil >>>>> <[email protected]> wrote: >>>>> > Why not? Now I don't want to hear anything about best practices, I >>>>> also had >>>>> > times when using variables like tblSomething, strSomething, >>>>> fltSomething and >>>>> > it still worked. Is there any other problem in that than simply >>>>> screwing >>>>> > some programmer's ethics? >>>>> ------------------------------------------- >>>>> >>>>> Data objects don't need to present object types in name. Sorry but >>>>> Customers or tblCustomers is the same thing. Why OVERWHELM >>>>> intellisense by stuffing every friging TABLE together? Sorry but it >>>>> is just sad design from my POV. YMMV. ;-> >>>>> >>>>> In a GUI having all txtBoxes together is good for ease of finding the >>>>> one you are looking for and you don't have too many to deal with, I >>>>> hope. >>>>> >>>>> Now putting the data type for each column really can tweak me as very >>>>> poor design. >>>>> >>>>> vcCustomerName, dtInvoiceDate, intInvoiceNumber. Why waste the >>>>> letters? Is there any benefit that you receive? >>>>> >>>>> I am a firm believer of KISS naming when we live in a strict type data >>>>> environment. >>>>> >>>>> >>>>> >>>>> -- >>>>> Stephen Russell >>>>> >>>>> Sr. Production Systems Programmer >>>>> CIMSgts >>>>> >>>>> 901.246-0159 cell >>>>> >>>> >>>> >>> >> >
