문제

C# 및 Java에서는 클래스 이름, 메서드 이름, 지역 변수 등에 거의 모든 문자를 허용합니다.ASCII가 아닌 문자를 사용하여 열악한 편집기와 분석 도구의 경계를 테스트하고 일부 사람들이 읽기 어렵게 만드는 것은 나쁜 습관입니까, 아니면 미국의 오만함이 이에 대한 유일한 주장입니까?

도움이 되었습니까?

해결책

나는 영어를 고수할 것입니다. 일반적으로 해당 코드를 작업하는 사람이 누구인지 알 수 없고 빌드/테스트/버그 추적 진행에 사용되는 일부 타사 도구에 문제가 있을 수 있기 때문입니다.비독일어 키보드에 äöüß를 입력하는 것은 단순히 PITA에 불과합니다. 저는 단순히 소프트웨어 개발에 참여하는 사람이라면 누구나 영어를 말해야 한다고 믿습니다. 그러나 어쩌면 그것은 비영어권 사용자로서의 저의 오만일 수도 있습니다.

당신이 "미국의 오만함"이라고 부르는 것은 당신의 프로그램이 국제 변수 이름을 사용하는지 여부가 아니라 프로그램이 "Währung"과 "Wahrung"이 같은 단어라고 생각할 때입니다.

다른 팁

나는 그것이 전적으로 코드베이스에서 작업하는 사람에 달려 있다고 말하고 싶습니다.

공통 언어를 공유하는 소규모 개발자 그룹이 있고 해당 언어를 구사하지 못하는 사람이 코드 작업을 할 필요가 없다면 계속해서 원하는 문자를 사용하십시오.

다양한 문화와 언어를 가진 사람들이 코드 작업을 해야 한다면 영어를 사용하는 것이 가장 좋습니다. 왜냐하면 영어는 전 세계 거의 모든 사람들의 공통 분모이기 때문입니다.

귀하의 비즈니스가 영어를 구사하지 않고 도메인 중심 디자인에 뭔가가 있다고 생각한다면 또 다른 측면이 있습니다.개발자로서 번역 오버헤드 없이 비즈니스와 동일한 도메인 언어를 어떻게 사용할 수 있습니까?

이는 영어와 노르웨이어와 같은 언어 간 번역뿐만 아니라 다른 단어 간 번역도 의미합니다.우리는 엔터티 클래스와 서비스에 대해 비즈니스와 정확히 동일한 단어를 사용해야 합니다.

나는 포기하고 모국어를 사용하는 것이 더 쉽다는 것을 알았습니다.이제 내 코드에서 동일한 단어를 사용하므로 도메인 전문가와 대화하기가 더 쉬워졌습니다.그리고 시간이 지나면 헝가리 표기법 없이 코딩하는 데 익숙해진 것처럼 익숙해집니다.

나는 어떤 명명 규칙(및 그 문제에 대해서는 다른 코딩 규칙)을 사용하여 문제를 해결하는 개발 팀에서 일했습니다.믿거나 말거나, 코드에서 ä와 ö를 처리해야 하는 것이 제가 사임하게 된 요인이었습니다.저는 핀란드인이지만 핀란드어 키보드에서는 중괄호와 대괄호를 쓰기가 어렵기 때문에 미국 키보드 설정으로 코드를 작성하는 것을 선호합니다(곱슬머리의 경우 오른쪽 Alt와 7, 0을 사용해 보세요).

그래서 나는 ASCII 문자를 고수한다고 말합니다.

여기에 예가 있습니다 그리스 문자를 영어 이름으로 바꾸는 것보다 읽기 쉽기 때문에 ASCII가 아닌 식별자를 사용한 곳입니다.키보드에 θ나 ψ가 없는데도 (복사해서 붙여넣기에 의존했습니다.)

그러나 이것들은 모두 지역 변수입니다.비ASCII 식별자를 공개 인터페이스에서 제외하겠습니다.

때에 따라 다르지:

  • 귀하의 팀은 ASCII 사용을 요구하는 기존 표준을 준수합니까?
  • 귀하의 모국어를 구사하지 못하는 사람이 귀하의 코드를 재사용하거나 읽을 가능성이 있습니까?
  • 온라인으로 도움을 요청해야 하므로 코드 샘플을 있는 그대로 복사하여 붙여넣을 수 없는 시나리오를 상상하시나요?
  • 전체 도구 모음이 코드 인코딩을 지원한다고 확신하시나요?

위 항목 중 하나라도 '예'라고 대답했다면 ASCII만 사용하세요.그렇지 않은 경우 위험을 감수하고 진행하십시오.

지나치면 그 밖의 전제조건 그런 다음 하나의 추가 (IMHO 더 중요) 하나가 있습니다. 기호를 입력하는 것이 얼마나 어려운지.

일반 en-us 키보드에서 문자 ç를 입력하는 유일한 방법은 Alt를 누른 상태에서 숫자 키패드에서 0227을 누르거나 복사하여 붙여넣는 것입니다.

이것은 빠르게 타이핑하는 데 큰 장애물이 될 것입니다.강제로 하지 않는 한 이와 같은 사소한 일로 인해 코딩 속도가 느려지는 것을 원하지 않을 것입니다.국제 키보드가 이 문제를 완화할 수 있지만, 국제 키보드 등이 없는 노트북에서 코딩해야 한다면 어떻게 될까요?

문제의 일부는 Java/C# 언어와 해당 라이브러리가 다음과 같은 영어 단어를 기반으로 한다는 것입니다. if 그리고 toString().저는 개인적으로 코드를 읽는 동안 영어가 아닌 언어와 영어 사이를 전환하고 싶지 않습니다.

그러나 데이터베이스, UI, 비즈니스 로직(메타포 포함)이 이미 영어가 아닌 언어로 되어 있는 경우 모든 메서드 이름과 변수를 영어로 번역할 필요가 없습니다.

개발팀의 누군가가 ASCII만 지원하는 SDK를 사용하고 있거나 코드를 오픈 소스로 만들고 싶다면 많은 문제가 발생할 수 있기 때문에 저는 ASCII 문자를 고수할 것입니다.개인적으로 저는 해당 언어를 구사하지 못하는 사람을 프로젝트에 참여시킬 계획이 없더라도 그렇게 하지 않을 것입니다. 왜냐하면 당신은 사업을 운영하고 있고 사업을 운영하는 사람은 자신의 사업이 확장되기를 원할 것 같기 때문입니다. , 이는 오늘날의 시대에 국경을 초월하는 것을 의미합니다.제 생각에는 영어가 영역의 언어이며 변수 이름을 다른 언어로 지정하더라도 프로그래밍에서 ASCII가 아닌 문자를 사용할 의미가 거의 또는 전혀 없다는 것입니다.UTF8 데이터를 처리하는 경우 이를 처리하는 것은 언어에 맡기십시오.내 iPhone 프로그램(전화기와 서버 사이에 이동하는 수많은 사용자 데이터 포함)은 UTF8을 완벽하게 지원하지만 소스 코드에는 UTF8이 없습니다.거의 아무 이득도 없이 그렇게 큰 벌레 캔을 여는 것 같습니다.

ASCII가 아닌 문자를 사용하는 데는 또 다른 위험이 있지만 아마도 모호한 경우에만 문제가 될 것입니다.허용되는 문자는 다음과 같습니다. 한정된 방법적인 면에서 Character.isJavaIdentifierStart(int) 그리고 Character.isJavaIdentifierPart(int), 유니코드로 정의됩니다.그러나 사용되는 유니코드의 정확한 버전은 Java 플랫폼의 설명서에 지정된 대로 버전에 따라 다릅니다. java.lang.문자.

문자 속성은 한 유니코드 버전에서 다음 버전으로 조금씩 변경되므로 한 버전의 Java에서는 유효하지만 다음 버전에서는 유효하지 않은 식별자를 가질 수 있습니다(아마도 거의 발생하지 않음).

이미 지적했듯이, 메소드 이름이 대부분 언어와 일치하지 않는 한, 읽는 동안 끊임없이 언어를 전환하는 것은 약간 이상합니다.

제가 말하고 말할 수 있는 스칸디나비아 언어와 독일어의 경우 최소한 표준 대체어를 사용하는 것이 좋습니다.

ä/æ -> ae, ö/ø -> oe, å -> aa, ü -> ue

등.다른 사람들이 키보드/키맵을 변경하지 않고 원래 문자를 입력하는 것이 어렵다고 생각할 수 있는 경우를 대비해서입니다.개발자가 제3의 언어(예: 프랑스어 ç 포함)를 사용하고 이를 수행하지 않은 코드베이스로 갑자기 작업해야 한다고 생각해 보세요.효율적으로 입력하기 위해 2개 이상의 키맵 사이를 전환하는 것은 내 경험상 고통스러울 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top