I'm a tibbler - and proud of it. My application required a foundation that allowed complete customization of anything based on any client need period.
Using "tbl", "str", "obj", "ary" etc as prefixes to a defined "Root" (Product, News, Page, etc) allowed me to construct everything in such a way that any new functionality, or data table, simply needs a "tbl(New Root)" and a defined object "obj(New Root)". The result is that common requirements of CRUD automatically fall in line and presents readable (according to others) code that allows them to follow what the intended functionality, data types and expected results should be. AKA - the programming becomes self documenting just by the little hints left behind in variable names and procedures. Same thing goes for form inputs on the user side - (txt, drp, rdbtn) prefixes paired with database column names allows form handling logic on the backend to target those named prefixes out of any other incoming form data and construct appropriate SQL statements for handling those targeted values. Simply adding a new DB column, and making a "txt(New Column)" input results in all the SQL statements to automatically fold the new value in with no further programmer intervention. This practice has resulted in TREMENDOUS efficiency, customization possibilities, and elimination of redundant or over looked steps because everything has been constructed with a foundation of these prefixes so tomorrow’s challenges really become less challenging. I'm off my soapbox now, so let the "holier than thou" start the bashing... On Nov 26, 11:17 am, Jamie Fraser <[email protected]> wrote: > 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- Hide quoted text - > > - Show quoted text -
