You are here: Re: Case sensitivity in programming languages. « PHP Programming Language « IT news, forums, messages
Re: Case sensitivity in programming languages.

Posted by Tony Marston on 08/10/06 12:21

"Mark A. Boyd" <mblist@sanDotrr.com.invalid> wrote in message
news:Xns981A678D8E11BmblistssanDotrrcom@66.75.164.119...
> On Wed, 09 Aug 2006 09:45:24 GMT, Tony Marston posted in comp.lang.php:
>
>>
>> "Mark A. Boyd" <mblist@sanDotrr.com.invalid> wrote in message
>> news:Xns9819C73F142DCmblistssanDotrrcom@66.75.164.119...
>>> The august Jerry Stuckle posted August:
>>>
>>>> Tony Marston wrote:
>>>
>>> [snip]
>>>
>>>>> I have told you several times. When most people read a word it has
>>>>> the same meaning regardless of case. To suddenly say that by simply
>>>>> changing the case of one letter you prodce a totally different word
>>>>> is confusing. Maintaining someone else's program where the same word
>>>>> is used in multiple places, but because of small differences in case
>>>>> it actually becomes a different word would be a nightmare to most
>>>>> people.
>>>>
>>>> Fine. Go teach English.
>>>
>>> [snip]
>>>
>>> And elsewhere today, Tony Marston wrote:
>>>
>>>>> That's just your opinion. I still firmly believe that most
>>>>> programmers would be confused if they encountered a word with the
>>>>> same spelling but different case which actually meant something
>>>>> totally different. This is not the case in any spoken language, nor
>>>>> is it the case most computer languages. It is confusing, it leads to
>>>>> obfuscated and unmaintainable code, therefore it is a bad thing.
>>>>> Period. End of story.
>>>
>>> There you go again. Please don't teach English. You might put another
>>> bad mark on our (U.S.) already poor educational system if you are
>>> expected to mark a paper by a student named Mark. It may never dawn on
>>> you (even in May) that Dawn wrote about Him not about him; that a lamp
>>> can help if installing a LAMP at night; that not all dinnerware in
>>> China is china; that
>>> a march need not be scheduled in March, etc., etc., etc.
>>>
>>> Tony, if you can't easily see the differences in the words used in the
>>> above paragraph - and understand that case changes their meaning to
>>> something totally different - then I don't think you'll ever be
>>> comfortable
>>> with case-sensitive programming languages. I *seriously* doubt that it
>>> confuses most programmers when working with written or programming
>>> languages. I didn't really think you had this trouble with the written
>>> language either, but now that you've reiterated your problem and called
>>> it the "End of story", I choose to believe you. Your inability to
>>> appreciate the differences determines the "good" or "bad" of it for you
>>> and only you.
>>>
>>> IMO obfuscated and unmaintainable code is written by programmers who
>>> are just learning, don't care, in a mad rush, or are doing so
>>> intentionally. I can't see where the case-sensitivity of a chosen
>>> programming language would
>>> be the cause. After all, one should know whether the language supports
>>> it or not.
>>
>> Do you support the idea that the ability to create different functions
>> with the *same spelling* but *different case* is a good thing? Can you
>> point to any online resources which support this idea?
>
> AFAIR, you're the only person who has mentioned this. Others have stated
> that, most often, different case signifies variable, class, constant, etc.
>
> While I feel no compulsion to research who supports what, I personally
> wouldn't have a problem using a language with that ability. But I would
> discourage the team from using it that way (I care). If somebody did use
> it
> that way, it is as easy to spot as a simple typo: fileread() vs.
> filread().
>
> Good or bad? Neither - for those of us who can easily see the case
> differences in the code and in the written language. It's just the way the
> language works. It would be bad for you, though. I suspect your inability
> to
> easily see or appreciate these differences is the root cause of your
> objection to case sensitivity - and for this entire thread.
>
> When I was punching code on a panel, I wasn't surprised when a program
> didn't
> do what I expected because I missed a digit or two. The same goes for
> typewritten programming languages. After all, the only difference between
> upper and lower case is in the numbers sent to the CPU.
>
> If a language converts my typing to the identical numbers/instructions, so
> be
> it. It is documented. It is neither good nor bad.
>
> If a language converts my typing to different numbers/instructions, so be
> it.
> It is documented. It is neither good nor bad.

You are still missing a fundamental point. For many decades all competent
programming standards have naming conventions which state that variables and
functions should be given meaningful names which identify the data that they
hold or the function that they perform. Do you see that? The NAME is
significant, which means the *spelling* and not the usage of upper or lower
*case*.

So if I have four different functions which read a file in different ways
then I give them appropriate names which by long standing and traditional
conventions are all different, such as readByKey(),
readSerially(),readNext() and readPrevious(). Even though the language *may*
be case sensitive and allow the *same spelling* but *different case* to mean
a *different object*, any programmer who deliberately create a series of
different functions with the same spelling but different case, such as
readfile(), readFile(), ReadFile() and READFILE(), is in violation of those
long standing and traditional standards. Most programmers would consider the
use of such techniques as leading to obfuscated and unmaintainable code.

I *do not* accept the idea that just because *some* languages allow this
disgraceful state of affairs that it is now the *new standard* and should
therefore be applied to all languages.

Hands up those who agree with me.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

 

Navigation:

[Reply to this message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация