• (cs) in reply to ammoQ

    ammoQ:

    Example one: A company regulary changes product numbers. Don't ask me why, enough to say they do it. As a result, if you have internal IDs (and use them for all references), you have to update one record. If you rely on the product number (the old system did that), you have to work through 15+ tables to update the product number there.

    Or you could set it up to cascade updates and it would make the changes for you.  I think it's a bad habit to use autonumber fields when there is a perfectly valid primary key.  Case in point - my coworker who created an autonumber id field in a table of zipcodes.  He couldn't figure out why his queries were running so slow... maybe because there was no index on the zipcode field?  There was no purpose for creating the autonumber field, he just did it because that's what he always did.

  • (cs) in reply to Candle
    Candle:
     
    Not to be too pedantic on a WTF, but...

    SELECT blah, `company ID`, blah2, CompanyID, `blah3 with spaces` FROM [table] JOIN [table2] ON table.Company ID = table2.joinField
     
    doesn't work, at least not in MS SQL 2000.  It really ought to be:

    SELECT blah, [company ID], blah2, CompanyID, [blah3 with spaces] FROM [table] JOIN [table2] ON table.Company ID = table2.joinField
     
    (except I would mark the JOIN as an INNER JOIN.)
     
    Tables and field names can be enclosed in brackets; the quotes only work if QUOTED_IDENTIFIER is set ON.  AND -- you need double quotes, not single quotes.  Single quotes ALWAYS mean a quoted string, never a table or field name.
     
    See Delimited Identifiers in SQL 2000 Books On Line.  (That topic has some really bad examples of using delimited identifiers when field names are reserved words -- an example shows field names of INSERT, UPDATE, DELETE, etc.  Yuck.)
     
    And yes, it's a bad idea to have spaces in table or field names.
     
    David W.
  • bp (unregistered) in reply to Eric Wise
    Anonymous:

    (...)
    situation where a new customer would request a quote, so a company record would be created in the SQL server system.  Then if they actually purchased something and became a real customer they'd get a record in the accounting system (peachtree) which would have its own id.  Periodically they export peachtree data into the sql server so it could be accessed through their custom
    (...)


    Yah, I've seen this before as well, where you need to map your own ID to a "remote" ID, but WTF using the same name with only a space to separate them?

    On the otherhand, it's a WTF if your going to use a system like this, to use native IDs at all IMO.

    BTW - Whats with having to submit the post twice? the CAPTCHA doesn't seem to work the first time...
  • (cs) in reply to mugs
    mugs:

    ammoQ:

    Example one: A company regulary changes product numbers. Don't ask me why, enough to say they do it. As a result, if you have internal IDs (and use them for all references), you have to update one record. If you rely on the product number (the old system did that), you have to work through 15+ tables to update the product number there.

    Or you could set it up to cascade updates and it would make the changes for you.  I think it's a bad habit to use autonumber fields when there is a perfectly valid primary key.  Case in point - my coworker who created an autonumber id field in a table of zipcodes.  He couldn't figure out why his queries were running so slow... maybe because there was no index on the zipcode field?  There was no purpose for creating the autonumber field, he just did it because that's what he always did.


    The problem is not if I have to issue one update statement or 15; the question is if the system has to update one record or 10000000 records. Performance, deadlocks, archive logs filling the harddisk, ...
  • (cs) in reply to Squig the Squog
    Anonymous:
    ammoQ:
    Anonymous:

    The simple answer is, you _do_ want to use a consistent approach with the upper and lower case letters, but you _don't_ want something like Employee *employee=new Employee();


    Why not? Things like this are quite common. As long as upper case consistently means "class", I see no problem.

    "Why not? Things like this are quite common. As long as XXX[space]X consistantly means 'internal', I see no problem."

    The problem is, as I was trying to allude to, that 'CustomerID'/'customerID' is exactly the same kind of "the same but different" arbitary decision that we really should be laughing and pointing at.


    In Java, there is a strong convention that upper class means "class" and lower class means "instance". This is not "arbitrary". Knowing this coding conventions, no educated programmer should have a problem understanding code like "Socket socket = new Socket();" and typos are found by the compiler.
  • (cs) in reply to DWalker59

    DWalker59:
    AND -- you need double quotes, not single quotes. Single quotes ALWAYS mean a quoted string, never a table or field name.

    They weren't single quotes. They were backquotes. They're valid table/field name quotes in some dialects of SQL - the one understood by MySQL, at least.

    Rik

  • (cs) in reply to Bustaz Kool
    Bustaz Kool:

    Candle:
    I know that a space is a valid characher in a table name (...)

    A space is NOT a valid character in a table name.  That's why you have to use delimiters.  And it's a bad idea to use them.

    So it's not a valid character, but it is valid if you use delimiters? That means that they are valid. eg, in sql server 2000:

    create table [this is a test] (c1 integer)
    select * from sysobjects where name like 'this%'
    drop table [this is a test]

    Worked ok for me. A space is perfectly valid. Not recommended, of course.

  • (cs) in reply to Maurits
    Maurits:
    Maurits:
    Object object = new ...

    er, Object object = something_that_returns_an_object() (new returns a pointer, duh)


    You think in C++; in Java, there are no pointers, so 

    Object object = new Object();

    is perfectly valid in Java. The same is true for C#, but because of different naming conventions,
    it would be 

    object Object = new object();

    ;-)

  • Fabian (unregistered) in reply to DWalker59
    DWalker59:
    Candle:
     
    Not to be too pedantic on a WTF, but...

    SELECT blah, `company ID`, blah2, CompanyID, `blah3 with spaces` FROM [table] JOIN [table2] ON table.Company ID = table2.joinField
     
    doesn't work, at least not in MS SQL 2000.  It really ought to be:

    SELECT blah, [company ID], blah2, CompanyID, [blah3 with spaces] FROM [table] JOIN [table2] ON table.Company ID = table2.joinField


    I could be mistaken, but I guess you would also need brackets around the "table.Company ID"  in the ON clause then. And where would you put those?
    Like so: [table.Company ID]? Or could you use table.[Company ID]?

    I wouldn't know, I have never used (and will hopefully never use) spaces in column names.

    Fabian
  • Steve (unregistered) in reply to spotcatbug
    spotcatbug:

    I do exactly this all the time. I would never mix-up "employee" and "Employee" in that example. However, if I did, the compiler would tell me about it pretty quickly. Classes and instances are not interchangeable like that.



    Exactly.  It depends how small the function is, but in a large body of code, it might be MORE difficult to read something like:

    Employee *e = new Employee();

    Then you're left wondering what "e" is half-way down the code.
    It's more descriptive to use "employee" and have a convention that classes are capitalized and local variables are not.
  • (cs)

    I agree with the posters saying that there are times when you want multiple ID fields.  For example, I'm designing some software for my Taekwondo school, and in my student table, I have a StudentID field, which is my primary key, and is your typical auto-increment integer field.  I also have a nullable SchoolAssignedID field, which allows the school to assign their own ID's to be used (SSN, for example).  That's potentially the case here.  The naming of the two columns is the only problem that I see here.

  • Ross' Replacement (unregistered)

    ugh, I ask myself that question EVERY DAY... why, WHY did I quit my last job for $this->POS('job');

    =(

  • (cs)

    You know the only thing scarey than this SQL example are all the people in this thread justifying stupid programming techniques just because they've ALWAYS used stupid programming techniques.

    I'm sorry, but you spend the first 12 years being taught that upper and lower case symbols represent the SAME letter.  Its built right into your brain to see i and I as the same symbol.  Yes, you can train yourself to be 99% accurate when using upper and lower case symbols as DIFFERENT symbols, and yes, the computer sees them a different symbols because to a computer, they ARE (and lazy compiler engineers didn't bother to add case insensitivity).  However, you still ulitmately end up with problems parsing a statement as you read it because two different parts of your brain argue about the interpretation of what you are reading.

    Laziness like that leads to programs that use Foo foo, FOo, FOO, FoO, FOO,foO, fOO, fOo as unqiue symbols and lead to widespread confusion and poor maintainability.  Yes, you can do it.  But just as you can drill a hole in your skull, you probably shouldn't - things are bound to get VERY messy and possibly tragic.

    You want to differentiate a class from and instance?  USE A PREFIX, it will be 100% clear, 100% of the time and your brain won't have to argue with itself (and people will be less likely to spontaneously offer you a drill for your head)

  • (cs) in reply to Xepol
    Xepol:

    You know the only thing scarey than this SQL example are all the people in this thread justifying stupid programming techniques just because they've ALWAYS used stupid programming techniques.

    I'm sorry, but you spend the first 12 years being taught that upper and lower case symbols represent the SAME letter.  Its built right into your brain to see i and I as the same symbol.  Yes, you can train yourself to be 99% accurate when using upper and lower case symbols as DIFFERENT symbols, and yes, the computer sees them a different symbols because to a computer, they ARE (and lazy compiler engineers didn't bother to add case insensitivity).  However, you still ulitmately end up with problems parsing a statement as you read it because two different parts of your brain argue about the interpretation of what you are reading.

    Laziness like that leads to programs that use Foo foo, FOo, FOO, FoO, FOO,foO, fOO, fOo as unqiue symbols and lead to widespread confusion and poor maintainability.  Yes, you can do it.  But just as you can drill a hole in your skull, you probably shouldn't - things are bound to get VERY messy and possibly tragic.

    You want to differentiate a class from and instance?  USE A PREFIX, it will be 100% clear, 100% of the time and your brain won't have to argue with itself (and people will be less likely to spontaneously offer you a drill for your head)



    I've NEVER heard a good logical reason for having case sensitivity in a programming language. As you say, 's' to a person is the same as 'S'. There's nothing inherent about 'Object' that makes it a class and 'object' that makes it an instance. It's just a case of "we've always done it like this, so it MUST be good!"

    Oh sorry, there is one single reason for case sensitivity:
    Distinguish 'MadElope' from 'MadeLope'. A surprisingly frequent problem.....

    Bah humbug.
     
  • (cs) in reply to RayS

    Case sensitivity is a Good Thing (TM).  That is to say, it is a useful tool in the hands of someone who knows how to use it well.

    The misuses you cite are not to be recommended, of course. :)

  • (cs) in reply to RayS
    RayS:


    I've NEVER heard a good logical reason for having case sensitivity in a programming language. As you say, 's' to a person is the same as 'S'. There's nothing inherent about 'Object' that makes it a class and 'object' that makes it an instance. It's just a case of "we've always done it like this, so it MUST be good!"

    Oh sorry, there is one single reason for case sensitivity:
    Distinguish 'MadElope' from 'MadeLope'. A surprisingly frequent problem.....

    Bah humbug.
     


    After doing an informal survey of co-workers, I've found the occurance of needing to distinguish between "MadElope" and "MadeLope" to be very small.  In fact, it's zero.  Please tell us what the heck those words mean, and why you find yourself often needing to distingish from them?

  • Edwin (unregistered) in reply to Steve
    Anonymous:

    Exactly.  It depends how small the function is, but in a large body of code, it might be MORE difficult to read something like:

    Employee *e = new Employee();

    Then you're left wondering what "e" is half-way down the code.
    It's more descriptive to use "employee" and have a convention that classes are capitalized and local variables are not.


    You should use names like:
    Employee manager = new Employee()
    or
    Employeer teamMember;
    etc. So use the variable name gives information instead of only showing it's type in lowercase.

    Edwin
  • (cs) in reply to Blue
    Blue:
    RayS:


    I've NEVER heard a good logical reason for having case sensitivity in a programming language. As you say, 's' to a person is the same as 'S'. There's nothing inherent about 'Object' that makes it a class and 'object' that makes it an instance. It's just a case of "we've always done it like this, so it MUST be good!"

    Oh sorry, there is one single reason for case sensitivity:
    Distinguish 'MadElope' from 'MadeLope'. A surprisingly frequent problem.....

    Bah humbug.
     


    After doing an informal survey of co-workers, I've found the occurance of needing to distinguish between "MadElope" and "MadeLope" to be very small.  In fact, it's zero.  Please tell us what the heck those words mean, and why you find yourself often needing to distingish from them?



    The reference he makes has nothing to do with the sensibility of the words, whether they're words or not, or anything of that nature.  They are, however, the most common way of showing how much different something can be by changing a single capital letter in the word/words.  By doing that, the idea is to show why case sensitivity is not such a good thing in code, etc. 

    Cheers 
  • (cs) in reply to Blue
    Blue:
    RayS:


    I've NEVER heard a good logical reason for having case sensitivity in a programming language. As you say, 's' to a person is the same as 'S'. There's nothing inherent about 'Object' that makes it a class and 'object' that makes it an instance. It's just a case of "we've always done it like this, so it MUST be good!"

    Oh sorry, there is one single reason for case sensitivity:
    Distinguish 'MadElope' from 'MadeLope'. A surprisingly frequent problem.....

    Bah humbug.
     


    After doing an informal survey of co-workers, I've found the occurance of needing to distinguish between "MadElope" and "MadeLope" to be very small.  In fact, it's zero.  Please tell us what the heck those words mean, and why you find yourself often needing to distingish from them?

    Yeah, that was kind of my point. There is virtually zero need for case sensitivity, except for amazingly rare spelling crashes from joined words. In all the years I've been using a case insensitive programming language I've only come across the problem once (and I can't remember what it was), and it was resolved quickly by changing the phrasing.

    Also to further expand on Edwin's point. A variable name being just it's type name in lower case is a cr@p idea. Use meaningful names for your variables and not only does your code become more readable, you lose the already flimsy justification for case sensitivity.
    A variable of type Employee called 'employee' tells me nothing the IDE itself isn't already capable of telling me. What the IDE can't tell me is what it's actually for - that's the programmer's job, and the best way to do that is by calling it something meaningful.
  • (cs) in reply to RayS
    RayS:
    Blue:
    RayS:


    I've NEVER heard a good logical reason for having case sensitivity in a programming language. As you say, 's' to a person is the same as 'S'. There's nothing inherent about 'Object' that makes it a class and 'object' that makes it an instance. It's just a case of "we've always done it like this, so it MUST be good!"

    Oh sorry, there is one single reason for case sensitivity:
    Distinguish 'MadElope' from 'MadeLope'. A surprisingly frequent problem.....

    Bah humbug.
     


    After doing an informal survey of co-workers, I've found the occurance of needing to distinguish between "MadElope" and "MadeLope" to be very small.  In fact, it's zero.  Please tell us what the heck those words mean, and why you find yourself often needing to distingish from them?

    Yeah, that was kind of my point. There is virtually zero need for case sensitivity, except for amazingly rare spelling crashes from joined words. In all the years I've been using a case insensitive programming language I've only come across the problem once (and I can't remember what it was), and it was resolved quickly by changing the phrasing.

    Also to further expand on Edwin's point. A variable name being just it's type name in lower case is a cr@p idea. Use meaningful names for your variables and not only does your code become more readable, you lose the already flimsy justification for case sensitivity.
    A variable of type Employee called 'employee' tells me nothing the IDE itself isn't already capable of telling me. What the IDE can't tell me is what it's actually for - that's the programmer's job, and the best way to do that is by calling it something meaningful.


    OK, I guess.  The example might have made more sense if the two words were more meaningful.  "Made" next to "Lope" just doesn't make sense.  "Mad Elope" barely does.  Just stuck on the context.  I'll get over it.

    To comment on your comment on Edwin's comment:
    While I totally agree that, when you know a variable of type Employee will be used to specifically represent a specific position such as "manager", it makes sense to call that variable "manager" (or some variation), what do you do in a generic method which is designed to handle all or any employees?   Simply breaking out the thesaurus and changing "employee" to "team member" doesn't add to the meaningfulness of the name.



  • (cs) in reply to Bustaz Kool
    Bustaz Kool:

    Candle:
    I know that a space is a valid characher in a table name (...)

    A space is NOT a valid character in a table name.  That's why you have to use delimiters.  And it's a bad idea to use them.



    A space IS a valid character in a table name.  The fact that it requires you to use a delimiter does not detract from its' validity.  If you can use it, it's valid.

    (This is TSQL/SQL Server 2000)

    CREATE TABLE [test table] (
        [some_value] [int] NULL
    ) ON [PRIMARY]
    GO



  • (cs) in reply to Blue

    I had a table with literally hundreds of fields including all sorts of strange characters, including '
    SQL Enterprise Manager "Table Design Mode" couldn't handle the 's - the change script it generated didn't escape / delimit everything properly.  But I was able to save the change script, fix it, and run it.
    So yes, space is valid.  Perhaps not wise - but sometimes (like when you're mirroring a legacy system) you don't have a lot of choice.

  • (cs) in reply to Blue
    Blue:
    OK, I guess.  The example might have made more sense if the two words were more meaningful.  "Made" next to "Lope" just doesn't make sense.  "Mad Elope" barely does.  Just stuck on the context.  I'll get over it.

    To comment on your comment on Edwin's comment:
    While I totally agree that, when you know a variable of type Employee will be used to specifically represent a specific position such as "manager", it makes sense to call that variable "manager" (or some variation), what do you do in a generic method which is designed to handle all or any employees?   Simply breaking out the thesaurus and changing "employee" to "team member" doesn't add to the meaningfulness of the name.

    As for the Mad/Elope example, well I just couldn't think of any genuine clashes from differing combinations of words, but they do occur from time to time, but they are rare.

    On to your comment on my comment to Edwin's comment... Well the most obvious question would be "what is the purpose, in this context, of using that employee object?

    Hypothetical Example #1: Creating a new employee
    'NewEmployee' is more meaningful than "employee". I won't even mention the sort of rubbish such as as "Int int = new Int;" Ugh. wtf kind of use is that to anyone? If you can't tell what a variable is used for by looking at it's name, it's got the wrong name. Writing the code in the first place is 1/10th of the job. Making it easier for the other 9/10th of the work maintaining the code later is well worth a little more effort adding clarity from the start.

    Example #2: Avoiding logic bugs with meaningful names
    If you see 'DeleteEmployee(EmployeeToPromote)' in the code, there's a fair suspicion there's a bug. If  you're just using generic names 'DeleteEmployee(employee)' isn't obviously wrong.

    Example #3: Interaction with case insensitive languages
    Prime example being .NET . Any public interface with case sensitivity issues will be causing big problems.
    e.g. if you've a method in C# that for whatever reason is being passed a Class and a class instance, eg 'Employee' and 'employee' you won't have problems - until it needs to be exposed to VB.NET code.

    There are more examples, but personally those 3 are more than enough to at least start questioning the C++ standard practice.
  • (cs) in reply to RayS
    RayS:
    Blue:
    OK, I guess.  The example might have made more sense if the two words were more meaningful.  "Made" next to "Lope" just doesn't make sense.  "Mad Elope" barely does.  Just stuck on the context.  I'll get over it.

    To comment on your comment on Edwin's comment:
    While I totally agree that, when you know a variable of type Employee will be used to specifically represent a specific position such as "manager", it makes sense to call that variable "manager" (or some variation), what do you do in a generic method which is designed to handle all or any employees?   Simply breaking out the thesaurus and changing "employee" to "team member" doesn't add to the meaningfulness of the name.

    As for the Mad/Elope example, well I just couldn't think of any genuine clashes from differing combinations of words, but they do occur from time to time, but they are rare.

    On to your comment on my comment to Edwin's comment... Well the most obvious question would be "what is the purpose, in this context, of using that employee object?

    Hypothetical Example #1: Creating a new employee
    'NewEmployee' is more meaningful than "employee". I won't even mention the sort of rubbish such as as "Int int = new Int;" Ugh. wtf kind of use is that to anyone? If you can't tell what a variable is used for by looking at it's name, it's got the wrong name. Writing the code in the first place is 1/10th of the job. Making it easier for the other 9/10th of the work maintaining the code later is well worth a little more effort adding clarity from the start.

    Example #2: Avoiding logic bugs with meaningful names
    If you see 'DeleteEmployee(EmployeeToPromote)' in the code, there's a fair suspicion there's a bug. If  you're just using generic names 'DeleteEmployee(employee)' isn't obviously wrong.

    Example #3: Interaction with case insensitive languages
    Prime example being .NET . Any public interface with case sensitivity issues will be causing big problems.
    e.g. if you've a method in C# that for whatever reason is being passed a Class and a class instance, eg 'Employee' and 'employee' you won't have problems - until it needs to be exposed to VB.NET code.

    There are more examples, but personally those 3 are more than enough to at least start questioning the C++ standard practice.


    Those are good examples.  It just seems silly to me, for example, to have a function such as GiveEmployeeRaise with a variable declared inside of it called employeeToGiveRaiseTo (or something like that)...  But I would certainly agree in a system of size/complexity, it would be more clear to people.   Must be an ego thing on my part. :)

    I'm also rather curious about your last statement - VB.NET is case insensitive?  Under what circumstances?  A handful of our class libraries at work are VB.NET, while 99% of them are C#.   I notice when changing the VB.NET code that it appears quite concerned indeed with what and how I capitalize when referring to classes and namespaces, as much so as C# is.  I may not be using them in a way that exposes the situation you're describing.






  • (cs) in reply to Blue
    Blue:
    RayS:
    Blue:
    OK, I guess.  The example might have made more sense if the two words were more meaningful.  "Made" next to "Lope" just doesn't make sense.  "Mad Elope" barely does.  Just stuck on the context.  I'll get over it.

    To comment on your comment on Edwin's comment:
    While I totally agree that, when you know a variable of type Employee will be used to specifically represent a specific position such as "manager", it makes sense to call that variable "manager" (or some variation), what do you do in a generic method which is designed to handle all or any employees?   Simply breaking out the thesaurus and changing "employee" to "team member" doesn't add to the meaningfulness of the name.

    As for the Mad/Elope example, well I just couldn't think of any genuine clashes from differing combinations of words, but they do occur from time to time, but they are rare.

    On to your comment on my comment to Edwin's comment... Well the most obvious question would be "what is the purpose, in this context, of using that employee object?

    Hypothetical Example #1: Creating a new employee
    'NewEmployee' is more meaningful than "employee". I won't even mention the sort of rubbish such as as "Int int = new Int;" Ugh. wtf kind of use is that to anyone? If you can't tell what a variable is used for by looking at it's name, it's got the wrong name. Writing the code in the first place is 1/10th of the job. Making it easier for the other 9/10th of the work maintaining the code later is well worth a little more effort adding clarity from the start.

    Example #2: Avoiding logic bugs with meaningful names
    If you see 'DeleteEmployee(EmployeeToPromote)' in the code, there's a fair suspicion there's a bug. If  you're just using generic names 'DeleteEmployee(employee)' isn't obviously wrong.

    Example #3: Interaction with case insensitive languages
    Prime example being .NET . Any public interface with case sensitivity issues will be causing big problems.
    e.g. if you've a method in C# that for whatever reason is being passed a Class and a class instance, eg 'Employee' and 'employee' you won't have problems - until it needs to be exposed to VB.NET code.

    There are more examples, but personally those 3 are more than enough to at least start questioning the C++ standard practice.


    Those are good examples.  It just seems silly to me, for example, to have a function such as GiveEmployeeRaise with a variable declared inside of it called employeeToGiveRaiseTo (or something like that)...  But I would certainly agree in a system of size/complexity, it would be more clear to people.   Must be an ego thing on my part. :)

    I'm also rather curious about your last statement - VB.NET is case insensitive?  Under what circumstances?  A handful of our class libraries at work are VB.NET, while 99% of them are C#.   I notice when changing the VB.NET code that it appears quite concerned indeed with what and how I capitalize when referring to classes and namespaces, as much so as C# is.  I may not be using them in a way that exposes the situation you're describing.


    Yes, VB.NET is case insensitive always. What you're seeing is not the language being case sensitive, but the VS.NET IDE auto-capitalising for you. This allows you the readability of 'NameWithLotsOfWords' while being able to type in 'namewithlotsofwords'. It also provides the side benefit of unofficial typo checking. If you type 'namewithlosofwords' and it doesn't auto-capitalise, you know you did something wrong.
    That's something I really miss moving to C# from VB.NET. I'm so used to being able to type 'system.' that I forget to start hitting that shift key needlessly several times per line. :)

    Caps in VB/VB.NET (and other case insensitive languages) are for presentation/human readability, which in a sufficiently large project becomes one of the top concerns.
  • Darshan Arney (unregistered)

    This looks like a self joining table layout.  Company ID being the primary key; CompanyID being the self-referenced company...  So, the parent company is assigned another company that exists within the same table. 

    The naming convention though is outrageous.  So much for self-documenting code!

  • seo tools group buy (unregistered)

    I love what you guys are up too. Such clever work and exposure! Keep up the very good works guys I’ve incorporated you guys to my own blogroll. seo tools group buy

Leave a comment on “Peeking On In”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article