2009-09-15 5 views
3

코딩 규칙에 대한 조언을 찾고 있습니다. 빈도 순으로 사용하는 기본 언어는 C#, JavaScript 및 ActionScript입니다. 그것들은 모두 ECMA 기반 언어이므로, 대부분 구문을 바꾸어 사용할 수 있습니다. 내가 코드를 작성하는 방식을 표준화하고 싶습니다.교차 언어 코딩 표준?

나는 코딩 표준에 관한 문서를 둘러 보았고 Microsoft, Adobe, Doug Crockford 및 내가 소유 한 다양한 서적의 저자를 비롯한 여러 저자들에 의해 발견되었습니다. 개별 표준의 대부분은 동일합니다. 예를 들어, 대소 문자를 사용하여 개체 식별자를 구별하지 마십시오. 그래 좋아.

그러나 이들은 몇 가지 방법으로, 특히 이름 지정 규칙에서 나에게 다릅니다. 예를 들어 개인 속성의 이름을 지정할 때 밑줄을 사용하거나 camel case와 메소드 이름을 파스칼 케이싱으로 구분합니다.

ActionScript와 JavaScript는 서로 다른 점이 많습니다. 언어가 많고 코드 작성량이 많기 때문에 JavaScript가 더 어려워집니다. 또한 IDE에서 자동 서식 지정 문제가 있습니다 (예 : JavaScript vs C#의 함수에서 여는 중괄호 배치).

이 문제에 어떻게 접근했는지 조언 해주세요. 내가 볼 수없는 큰 함정들? 나는 내가 현자 적 (pedantic)이 될 수도 있고 다른 사람의 기준에 순응하지 않아도되는 환경에서 일할만큼 운이 좋다는 것을 알고 있습니다. 나는 생산성과 좀 더 가독성이 좋은 코드를 좀더 늘리기를 희망한다. 감사.

+3

C# (ECMA-334)은 ECMA에 의해 표준화되었지만 ECMAScript (ECMA-262)는 JavaScript와 ActionScript를 좋아합니다. – dtb

+0

여는 중괄호의 배치는 IDE의 구성 옵션이며 기본 설정은 반드시 대부분의 개발자가 따르는 규칙 일 필요는 없습니다. IDE 개발자가 사용하는 접근 방식이 기본값 일 수 있습니다. 어떤 언어가 다른 언어와 다른 방식을 사용하고 있는지 말하지는 않지만, 선호하는 방식에 맞게 IDE를 구성 할 수 있습니다. 할 수 없다면 IDE를 변경하십시오 .-) – NickFitz

답변

7

관용구와 세미콜론을 사용한다는 사실에도 불구하고 C#에서 의미가있는 관용어가 반드시 자바 스크립트에서는 의미가 없을 수 있습니다 (반대의 경우도 마찬가지 임).

우리는 대부분 다른 스타일의 코딩을 사용합니다. 대부분의 경우 C#의 표준 Microsoft 스타일과 대부분의 경우 Javascript의 표준 jQuery 스타일입니다. 조금 이상하게 보일 수 있습니다 (파스칼 대 낙타의 경우는 JSON 컨테이너처럼 거의 부적절하기 때문에 "부적절한"케이스가있는 C# 오브젝트가 있음을 의미합니다).하지만 구h 주려고하지는 않습니다. 두 개의 개별 언어가 단일 문법으로 무엇입니까?

+0

저는 (커뮤니티의 영향을 많이받는) 코딩 표준을 제안하기로 결정했습니다. 그러나 모든 언어에 대해 하나의 스타일로 구h 주려고하는 대신, 두 개를 만들려면; 하나는 C# 용이고 다른 하나는 Javascript/Actionscript 용입니다. 좋은 답변을 주신 모든 분들께 감사드립니다. – user50494

6

경계를 넘는 하나의 표준을 만들려고하지 않고 언어 공동체 또는 제작자가 제안한 표준을 고수 할 것입니다. 그렇지 않으면 언어를 둘러싼 커뮤니티에서 열정적이며 활발한 개발자의 마음을 사로 잡는 경향이 있습니다.

우리는 델파이와 C#을 가진 내 고용주 중 한 명에게 그렇게하려고 시도했지만 아무도 행복하지 않았습니다.

0

내가 다른 사람의 표준을 준수하지 않아도 어디 환경에서 일할만큼 운이있어

개인적으로 전 C#에 대한 Microsoft 표준을 따르지 않는 대신, 내 모든 메소드 이름과 속성 이름은 camelCase를 사용합니다 (그러나 내 유형은 여전히 ​​UpperCase를 사용합니다). 그리고, 멤버 데이터를 꾸미므로 (로컬 변수, 속성 및/또는 매개 변수와 혼동 할 수 없도록)

Microsoft의 명명 규칙을 따르는 것이 왜 필요한지 알지 못합니다. IMO를 사용하지 않는 것이 좋을 때도 있습니다. Microsoft 유형을 하위 클래스로 분류 할 때 대/소문자 (예 : '추가')는 내 기본 메소드에서 Microsoft 메소드 (예 : '추가')를 구별합니다.

또한 C++을 작성할 때 표준 라이브러리 작성자 (해당 UpperCase를 사용하는 반면 lower_case를 사용하는 사람)와 동일한 명명 규칙을 따르지 않습니다.

그러나 다른 개발자가 좋아할 수도 있습니다. 예를 들어, 누군가가 C# 코드 예제에 댓글을 달았습니다. 그래서 여기에 답을 적어 놓았습니다. 내용이 아니라 명명 규칙에 대한 비판을하기 위해서입니다.

+2

나는 평균을내는 것을 의미하지는 않지만 나는 당신과 일하지 않기 때문에 기쁩니다 .- 일관성이 코딩 표준의 한 가지 이유이기는하지만 다른 것은 개발자 친숙입니다. 주어진 언어에 대해 일반적으로 허용되는 코딩 표준을 준수한다면 새로운 개발자는 자신의 코드베이스에보다 쉽게 ​​적응할 수 있습니다. –

0

이것은 코딩 표준이되는 표준이기 때문에 실제로 선호되는 문제입니다. 표준. 명백한 옳고 그른 점은 없으며 모든 언어의 커뮤니티 표준을 강화하는 데는 5 가지 언어로 자주 작업 할 때까지 많은 어려움이 있습니다. 다음 표준을 따르지 않고 시작할 수 없습니다.

필자가 전에 한 것은 같은 표준 (PHP, Java, Ruby)과 동일한 표준을 사용하는 것이 절대적으로 비실용적이었던 경우 동일한 표준을 사용하는 것입니다. (예를 들어 BASH 스크립트의 경우) 두뇌가 스위치를 만들기에 충분합니다.

하지만 정말로 당신과 (그리고 나머지 팀원들도) 동의합니다. 특정 코딩 표준 세트에서 생산성을 얻지 못하면 함께 작업하는 사람들과 동일한 표준을 가짐으로써 생산성을 높일 수 있습니다. 밑줄을 긋고 헝가리 낙타의 경우를 자세히 읽고 싶다면 전체 팀이 그것을 수행하는지 확인하십시오.

관련 문제