언어에서 대소 문자를 구분하지 않는 키워드 [닫기]

우리는 맞춤형 스크립팅 언어를 작성하려고합니다. 대소 문자를 구분하지 않는 키워드 를 제공하여 언어를 용서할 것을 제안했습니다 .

개인적으로 아이디어가 마음에 들지 않지만 팀에는 아이디어를 기대하는 사람이 거의 없어 최종 사용자를 행복하게 할 것입니다. FORTRAN, BASIC, SQL과 같은 언어의 예는 대소 문자를 구분하지 않음을 나타냅니다.

이것이 좋은 생각입니까?

최종 사용자가 누구인지 자문하십시오. C 또는 Javscript에서 프로그래밍 경험이 있거나 Unix에서 IT 경험이있는 사람이 작성해야한다면 대소 문자 구분이 올바른 방법 일 것입니다. 이것이 사용자가 기대하는 것이기 때문입니다. 그러나 대부분의 최종 사용자, 심지어 고급 사용자에게는 혼동을 줄 수 있습니다.

VB / VBA / VBScript는 대소 문자를 구분하지 않으므로 프로그래머가 아닌 사용자도 쉽게 언어를 익힐 수 있습니다. 정확하게 스크립트는 아니지만 많은 사용자가 접근하는 Excel 수식은 대소 문자를 구분하지 않습니다. 대부분의 글에서 대소 문자를 선택하면 텍스트가 다소 전문적이고 세련되게 보일 수 있지만 자체적으로 의미가 변경되지는 않습니다. 단어 의미를 . 그렇기 때문에 개발자가 아닌 개발자는 대소 문자를 구분하는 스크립팅 언어에 혼동 될 것이라고 생각합니다.

다시 말하지만, 이것은 기술적 선택이 아닙니다. 대상 고객을 잘 아는 사람들이 선택해야하는 제품 관리 선택입니다.

구현하기가 쉽지 않은지가 아니라 제시하려는 사용자 경험에 따라 결정해야합니다.

사용자가 대소 문자를 구분하지 않는 것이 더 쉬워지면 구현해야합니다.

포인트 SQL의 경우 대소 문자를 구분하지 않습니다. 대화 형 설정에서 사용하기가 매우 쉽습니다.

이 볼 수있는 또 다른 방법은 이제까지의 차이가 될 것입니다 keyword및 Keyword해당 언어로,이 차이는 사용자에게 의미가있을 것인가? 스크립팅 언어의 경우 대답은 "아니오"라고 말합니다.

프로그래밍 언어는 대소 문자를 구분해야합니다. 사람들은 이것에 매우 쉽게 적응할 수 있습니다. 그들은 대부분 소문자로 작업하고 기존 API에서 대소 문자 또는 모든 대문자 식별자를 조심해야한다는 것을 기억해야합니다.

언어를 대소 문자를 구분하지 않는 것이 분명해 보였습니다. 모든 컴퓨팅 시스템 및 해당 I / O 장치 (키보드, 프린터 및 디스플레이 장치)에서 소문자를 사용할 수 없었기 때문입니다. 프로그래밍 언어 구현은 대문자로 작성된 프로그램 만 허용해야했습니다. 왜냐하면 프로그램 만 표시하거나 인쇄 할 수 있기 때문입니다. 대소 문자를 구분해야하므로 대문자 와 대소 문자를 구분해야 소문자를 거부 할 수 있습니다. 소문자는 프로그래머가 원하는 것이었지만 항상 가질 수는 없었습니다. 대문자로 소리 친 프로그램으로 작업하기를 원하는 사람은 아무도 없었습니다. 하드웨어 제한 일뿐입니다.

한동안 터미널에서 케이스를 접는 것도 일반적이었습니다. 터미널이 대문자 만 표시 할 수 있지만 대문자와 소문자를 지원하는 컴퓨팅 시스템에 로그인해야하는 경우 터미널은 소문자를 대문자로 접습니다. 이것이 너무 오래되었다고 생각하십니까? "Apple II와 마찬가지로 Apple II Plus에는 소문자 기능이 없었습니다." (http://en.wikipedia.org/wiki/Apple_II_Plus) 초기 Apple 컴퓨터 사용자가 대소 문자가 혼합 된 BBS에 전화를 걸 때 터미널 에뮬레이터 (또는 호스트)는 모두 대문자로 접어야했습니다. 모든 대문자로 작성된 메시지는 당시 게시판에서 일반적이었습니다. 이 기능은 여전히 ​​Linux 커널과 같은 Unix와 유사한 운영 체제에서 찾을 수 있습니다. 예를 들어stty olcuc 쉘 프롬프트에서를 .Unix tty 라인 규칙은 출력시 소문자를 대문자로 매핑 할 수 있으며 입력시 대문자를 소문자로 매핑 할 수 있습니다. 이를 통해 소문자가없는 터미널에서 소문자 프로그래밍 언어로 작업 할 수 있습니다.

대소 문자 무감각은 현대화 된 국제 컴퓨팅 환경에서 잘 작동하지 않는 과거의 컴퓨터 시대의 구식 개념입니다. 다른 언어로 확장 하시겠습니까? 프랑스어는 어떻습니까 : È와 è는 동등하다고 생각하십니까? 아니면 일본인? 히라가나와 가타카나를 단지 사례로 간주하여 후일과 후 이루는 동일한 식별자입니까? 이러한 어리 석음에 대한 지원은 어휘 분석기를 크게 복잡하게하는데, 이는 전체 유니 코드 공간에 대해 대등 한 맵을 가져야합니다.

수학은 대소 문자를 구분합니다. 예를 들어, 대문자 시그마는 합산을 나타내는 반면, 소문자 시그마는 표준 편차와 같은 다른 것을 나타냅니다. 이것은 어려움없이 동일한 공식으로 발생할 수 있습니다. (프로그래밍 언어가 Σ와 σ를 동등하게합니까?)

영어 철자법은 민감합니다. 예를 들어, 많은 고유 명사는 일반 명사 또는 다른 어음 부분에 해당합니다. "may"는 동사이지만 "May"는 한 달 또는 여자의 이름입니다. 또한 약어 나 약어가 소문자로 쓰여 있으면 혼동 될 수 있습니다. SAT는 학력 적성 시험을 의미하는 반면 "sat"는 "sit"의 과거 분사입니다. 똑똑한 사람들은 세부 사항에주의를 기울이고 적절히 활용하십시오.

기본적으로 대소 문자를 구분하지 않는 1985 년 이래로 작성된 새로운 프로그래밍 언어는 두 번째로 이메일과 게시를하지 않는 사람들을위한 것입니다.

언어가 코드 생성 대상으로 사용되어 다른 언어로 코드를 번역하고 다른 언어가 대소 문자를 구분하는 경우 어떻게됩니까? 구별을 포착하려면 모든 이름을 어떻게 든 변환해야합니다. (이것은 기술적 인 결정이 아니며, 대상 청중의 정서적 취향 만 중요하다는 것은 우스운 일입니다.)

다른 운영 체제에서 파일을 가져올 때 Windows에서 사례 처리로 인한 성가신 문제를 살펴보십시오. 그것은 기술적 인 문제입니다. 대소 문자 구분 파일 시스템은 대소 문자를 구분하지 않는 외부 데이터에 문제가 있습니다.

일반적인 Lisp은 이상적인 접근 방식에 도달했습니다. 심볼 이름은 대소 문자를 구분하지만 토큰을 읽을 때 대문자로 접 힙니다. 이 즉, 토큰 foo, fOO, FOO및 Foo모든 나타낸다 같은 기호 : 이름 문자열로 저장되어있는 기호 "FOO". 또한이 동작은 기본 읽기 테이블 구성 일뿐입니다. 독자는 글자를 대문자, 소문자로 접거나 대소 문자를 뒤집거나 보존 할 수 있습니다. 마지막 두 가지 선택은 대소 문자를 구분하는 방언을 생성합니다. 이런 방식으로 사용자는 최대한의 유연성을 갖습니다.

실제 결정 요인은 이름이 같은 여러 항목을 얼마나 자주 갖고 싶어하는지입니다. 대소 문자 구분은 SQL에서 열 이름을 원하지 않기 때문에 SQL에서 작동합니다 SELECT. 다른 모든 줄은 Object object = new Object()클래스, 인스턴스 및 생성자를 참조하는 동일한 이름을 원 하기 때문에 Java에서 성가시다 .

즉, 대 / 소문자 구분은 이름을 오버로드하는 데 주로 유용하며 오버로드는 대부분 크고 복잡한 프로젝트에서 유용합니다. 스크립팅 언어와 같이 자주 사용하지 않는 경우 대소 문자를 구분하지 않으면 프로그래밍이 훨씬 간단 해집니다.

식별자가 대소 문자를 구분하지 않고 공백을 구분하지 않는 규칙 언어를 한 번 만들었습니다. 또한 동일한 식별자를 참조하는 별칭을 만들 수있었습니다. 예를 들어 ProgrammersStackExchange, 프로그래머 스택 교환 및 PSE는 모두 정확히 동일한 기호로 확인되어 상호 교환 적으로 사용될 수 있습니다.

도메인이 똑같은 것을 참조하는 매우 잘 알려진 방법이 많았 기 때문에 도메인이 매우 잘 작동했기 때문에 이름 충돌이 거의 없었습니다. 한 이름을 사용하여 쿼리를 입력하고 다른 이름을 사용하여 결과를 얻음으로써 아무도 놀라지 않을 것입니다. 언어 지원을 통해 도메인과 프로그래밍 언어 간 번역이 매우 쉬워졌습니다. 그러나 변수에 대한 모든 참조를 찾는 것과 같이 특정 작업을 더 어렵게 만들었습니다. 고맙게도 제 경우에는 이러한 상황이 거의 발생하지 않았거나 도움을주기 위해 도구를 쉽게 구축 할 수 있었지만 자신의 상황을 고려해야합니다.

스크립트 언어는 대소 문자를 구분한다고 가정합니다. 변수 이름이나 키워드에 잘못된 대소 문자를 사용하여 오타를 작성했는지 알려주는 컴파일러 또는 구문 검사기를 작성 하시겠습니까? 그렇지 않다면 언어를 대소 문자를 구분하지 않는 강력한 논거가 될 것입니다.

변수를 즉석에서 선언 할 수 있습니까? 그렇다면 대소 문자를 구분하여 논쟁 할 것입니다.

ATypo = 42; 

반대로

Atypo = 42; 

불필요하게 디버깅 시간을 요구하고 있습니다.

FORTRAN, BASIC, SQL과 같은 언어의 예는 대소 문자를 구분하지 않음을 나타냅니다.

FORTRAN 및 SQL (및 COBOL)이 대소 문자를 구분하지 않는 이유는 원래 문자 세트가 대문자 만있는 머신에서 사용하도록 원래 설계 되었기 때문입니다. 해당 언어에서의 대소 문자 구분 (적어도)은 언어 디자인 선택보다 역사적인 유물입니다.

이제는 더 관대하게 대소 문자를 구분할 수 있다고 주장 할 수 있지만, 반대편에서는 대소 문자 구분으로 인해 대소 문자를 구분하기 때문에 대소 문자 구분이 더 읽기 쉬운 코드가된다는 것입니다.

대소 문자 구분은 유해한 것으로 간주됩니다.

인생은 대소 문자를 구분하지 않으며 사용자 나 프로그래머도 마찬가지입니다.

대소 문자 구분 언어는 대소 문자를 구분하지 않는 비교가 어려운 제한된 시스템의 역사적 사고입니다. 이 장애는 더 이상 존재하지 않으므로 대소 문자를 구분하는 컴퓨터 시스템을 다시 만들 이유가 없습니다.

대소 문자 구분은 악의적 이라고 말할 수 있습니다. 사용자의 편의보다 컴퓨터의 편리함이 우선하기 때문입니다.

(관련, 몇 년 전, 일부 천재인은 그의 이름이 모든 대문자로되어 있기 때문에 신용 카드 청구서 지불을 거부했지만 그는 대소 문자를 혼합하여 철자를 썼다. 유효한 지불 요구 판사는 그 주장을 정당한 것으로 간주했다).

개인적인 경험으로는 대소 문자를 구분하는 언어와 둔감 한 언어 사이에 큰 차이가 없습니다.

더 중요한 것은 프로그래머가 코드에 보관 해야하는 명명 및 구조적 규칙이며 컴파일러 나 파서는 그를 검사하지 않습니다. 어떤 종류의 규칙을 고수하면 적절한 이름을 쉽게 알 수 있으며 (변수 이름을 checkOut 또는 CheckOut으로 지정한 경우에는 생각하지 않을 것입니다) 코드는 대소 문자를 구분하고 읽기 쉽습니다.

CheckOut과 checkOut과 checkout 그리고 cHeCkOuT와 CHECKOUT을 같은 의미로 사용해서는 안됩니다. 가독성을 떨어 뜨리고 그러한 종류의 코드를 더 고통스럽게 이해합니다 (그러나 코드의 가독성을 파괴하기 위해 할 수있는 나쁜 일이 있습니다).

어떤 종류의 규칙을 사용하면 예를 들어 다음과 같이 볼 수 있습니다.

CheckOut.getInstance ()-checkOut.calculate ()라는 클래스의 정적 메소드-_checkOut.calculate ()라는 변수 또는 공용 필드에 보관 된 객체의 메소드-CHECKOUT이라는 개인 필드에 보관 된 객체의 메소드입니다. -최종 정적 또는 상수 필드 / 변수입니다.

다른 파일이나 파일의 일부를 확인하지 않고. 코드를 더 빨리 읽습니다.

Java, PHP, Action Script, JavaScript, C ++ 등 자주 사용하는 언어에서 비슷한 규칙을 사용하는 개발자가 많이 있습니다.

드문 경우이지만 대소 문자를 구분하지 않으면 화를 낼 수 있습니다. 예를 들어 클래스 이름에 CheckOut을 사용하고 변수에 checkOut을 사용하려는 경우 서로 충돌하기 때문에 사용할 수 없습니다. 그러나 대소 문자를 구분하고 명명 규칙에 사용하는 프로그래머의 문제입니다. 대소 문자를 구분하지 않는 언어로 표준 접두사 또는 접미사를 가진 규칙을 가질 수 있습니다 (VB로 프로그래밍하지 않지만 많은 VB 프로그래머가 이러한 종류의 명명 규칙을 가지고 있음을 알고 있습니다).

한마디로 : 대소 문자 구분이 더 좋습니다 (객체 지향 언어에만 해당). 대부분의 개발자는 대소 문자 구분 언어를 사용하고 대부분은 대소 문자 구분에 따른 이름 지정 규칙을 사용하므로 대소 문자를 구분하는 언어가 더 좋을 것입니다. 어떤 종류의 수정없이 규칙을 고수 할 수 있습니다. 그러나 그것은 객관적인 주장이 아니라 오히려 객관적인 주장이 아닙니다 (실제 단점이나 대소 문자 구분의 좋은 측면을 기반으로하지 않음)-좋은 개발자와 관련하여 볼 때 bAd DeVeLoPeR가 악몽 코드를 생성 할 수는 없기 때문에 볼 수 없기 때문에 대소 문자를 구분하더라도 큰 차이는 없습니다.

프로그래밍 언어는 대소 문자를 구분하지 않아야합니다.

요즘 많은 언어가 대소 문자를 구분하는 주된 이유는 단순히화물 문화 언어 디자인입니다. 그리고 다른 많은 것들과 마찬가지로, C는 이것을 명백히 잘못했습니다.

이것은 실제로 C와 UNIX의 원동력 중 하나입니다. 구현하기 쉬운 나쁜 솔루션과 구현하기 어려운 좋은 솔루션 중에서 선택할 수있는 경우 나쁜 솔루션을 선택하고 혼란을 해결하는 부담을 사용자. 이것은 마치 멍청한 것처럼 들릴 수 있지만, 그것은 사실입니다. "더 나쁜 것이 더 나은 원칙"으로 알려져 있으며 C 및 C ++로 인해 지난 수십 년 동안 수십억 달러의 피해를 직접 담당하여 결함이 많고 안전하지 않은 소프트웨어를 작성하기가 너무 쉽습니다.

대소 문자를 구분하지 않는 것이 훨씬 쉽습니다. 대소 문자를 구분하지 않는 방식으로 모든 것이 일치하는지 확인하는 추가 작업을 수행하기 위해 어휘 분석기, 구문 분석기 및 기호 테이블이 필요하지 않습니다. 그러나 두 가지 이유로 나쁜 생각이기도합니다.

• 먼저, 특히 스크립팅 언어를 구축하는 경우 한 곳에서 "myObject"라고하고 다른 곳에서는 "MyObject"라고 부르는 간단한 오타가 있습니다. 여기에서는 분명히 동일한 객체를 참조하지만 대문자와는 약간 일치하지 않습니다. , 런타임 오류로 바뀌지 않습니다. (이것은 파이썬과 같이 이것을 잘못하는 스크립팅 언어의 주요 어려움으로 악명 높습니다.)
• 둘째, 대소 문자 구분이 없다는 것은 대소 문자 를 바꾸는 것만으로 동일한 단어가 같은 범위에서 서로 다른 두 가지를 지칭하도록 대소 문자 구분을 남용 할 수 없다는 것을 의미합니다 . 혹시 C 환경에서 Windows 코드와 함께 작업했고, 같은 추한 선언으로 실행 한 경우 HWND hwnd;, 당신은 내가 무슨 말을하는지 알 수 있습니다. 그런 식으로 글을 쓰는 사람들은 꺼내서 찍어야하며 대소 문자를 구분하지 않으면 대소 문자 구분 남용이 코드에 들어 가지 않습니다.

그래서 그것을 올바르게 얻기 위해 추가 노력을하십시오. 결과 코드는 더 깨끗하고, 읽기 쉽고, 버그가 적으며, 사용자의 생산성을 높이고 프로그래밍 언어의 궁극적 목표가 아닌가?

누군가가 "대소 문자 구분을 통해 코드를 쉽게 읽을 수있다"고 믿을 수 없습니다.

가장 확실하지 않습니다! 나는 회사와 회사 (공개 변수 회사, 일치하는 개인 변수 회사)라는 변수를 동료의 어깨 너머로 살펴 보았고 글꼴과 색상을 선택하면 두 사람 사이의 차이를 구별하기가 매우 어려워졌습니다.

올바른 문장은 "대소 문자를 혼용하여 코드를 쉽게 읽을 수 있도록"해야합니다. 예를 들어 회사 이름이 아닌 CompanyName 및 CompanyAddress라는 변수가 훨씬 더 분명합니다. 그러나 내가 아는 언어는 소문자 변수 이름 만 사용하도록합니다.

내가 아는 가장 미친 컨벤션은 "대문자 공개, 소문자 비공개"입니다. 그냥 문제를 요구하고 있습니다!

내 실수에 대한 나의 취지는 "조용히 실패하는 것이 아니라 가능한 한 시끄럽게 실패하지만 가능한 것으로 보인다"는 것이다. 그리고 컴파일 시간보다 빠르지 않습니다.

대문자를 사용하려고 할 때 실수로 소문자 변수를 사용하는 경우 동일한 클래스 내에서 변수 를 참조하는 경우 종종 컴파일 됩니다 . 따라서 컴파일 및 런타임 모두에서 성공한 것처럼 보이지만 미묘하게 잘못된 일을하고 오랫동안 감지하지 못할 수 있습니다. 문제가 있음을 감지하면

개인 변수에 접미사가있는 규칙 (예 : 회사 공용 변수, CompanyP 개인 변수)을 사용하는 것이 훨씬 좋습니다. 아무도 실수로 두 가지를 섞지 않을 것이며 그들은 지능적으로 함께 나타납니다.

이것은 사람들이 헝가리 표기법에 반대하는 이의를 제기하는데, 여기서 접두사가 붙은 개인 변수 pCompany는 정보의 좋은 장소에 나타나지 않을 것입니다.

이 컨벤션은 끔찍한 대문자 / 소문자 컨벤션의 모든 장점을 가지고 있으며 그 단점도 없습니다.

사람들이 변수를 구별하기 위해 대소 문자를 구분해야한다고 생각한다는 사실은 내 생각에 상상력과 상식이 모두 부족하다는 것을 보여줍니다. 또는 슬프게도, 인간의 양은 "항상 그렇게 된 방식"이기 때문에 대회를 따르는 습관과 같습니다.

서로 관련이 있더라도 함께 작업하는 것이 명확하고 분명하게 달라집니다 !!

적절한 이유없이 대소 문자를 구분해서는 안됩니다. 예를 들어, 유니 코드와의 대소 문자 비교를 다루는 것은 나쁜 일이 될 수 있습니다. 구 언어의 대소 문자 구분 (또는 부족)은 요구가 매우 다르기 때문에 중요하지 않습니다 .

이 시대의 프로그래머는 대 / 소문자를 구분합니다.

대 / 소문자를 구분하면 코드를보다 쉽게 ​​읽고 프로그래밍 할 수 있습니다.

• 사람들 은 대소 문자를 올바르게 사용하기가 더 쉽다는 것을 알게 됩니다.

• 대소 문자가 다른 동일한 단어가 관련 항목을 참조 할 수 있도록 CamelCase를 허용 / 장려합니다. Car car; 따라서 이름 지정된 변수 car는 유형으로 작성됩니다 Car.

• ALL_CAPS_WITH_UNDERSCORES는 많은 언어에서 규칙에 따라 상수를 나타냅니다.

• all_lower_with_underscores는 멤버 변수 또는 다른 것에 사용될 수 있습니다.

• 모든 최신 프로그래밍 도구 (소스 제어, 편집기, diff, grep 등)는 대소 문자를 구분하도록 설계되었습니다. 대소 문자를 구분하지 않는 언어를 만들면 프로그래머가 당연하게 생각하는 도구와 관련하여 영원히 문제가 발생합니다.

• 언어가 해석 될 경우 대소 문자를 구분하지 않는 코드 구문 분석으로 인해 성능이 저하 될 수 있습니다.

• 영어 이외의 문자는 어떻습니까? 콥트어, 중국어 및 힌디어를 절대 지원하지 않기로 결정하고 있습니까? 언어를 기본적으로 UTF-8로 설정하고 대문자 또는 소문자로 문자가없는 일부 언어를 지원하는 것이 좋습니다. 키워드에서 이러한 문자를 사용하지는 않지만 다양한 도구에서 대소 문자 구분 기능을 해제하기 시작하면 (예 : 파일에서 항목을 찾기 위해) 초현실적이고 불쾌한 경험이 생길 수 있습니다.

장점은 무엇입니까? 언급 한 3 개 언어는 1970 년대 또는 그 이전의 언어입니다. 현대 언어는 이것을하지 않습니다.

반면에, 최종 사용자를 실제로 행복하게 만드는 것은 세상에 작은 빛을 가져옵니다. 그것이 실제로 사용자의 행복에 영향을 미치면 그렇게해야합니다.

최종 사용자에게 실제로 간단하게 만들고 싶다면 대 / 소문자 구분 / 민감도보다 더 나은 작업을 수행 할 수 있습니다. 스크래치를 살펴보십시오 ! 만화 고양이가 적고 비즈니스 친화적 인 색상이 적으며 내가 본 가장 친숙한 언어에 대해 알고 있으며 아무것도 쓸 필요가 없습니다! 그냥 생각이야