다른 사람이 프로그래밍에서 가장 어려운 부분 중 하나 인 명명 클래스와 메소드를 찾으십니까? [닫은]

그래서 저는 웹 서비스를 통해 공급 업체에 도움 문서를 요청 해야하는이 클래스에서 일하고 있습니다. 내가 이름을하려고 DocumentRetriever, VendorDocRequester, DocGetter,하지만 그들은 바로 소리를하지 않습니다. 나는 적절한 단어를 찾으려고 30 분 동안 dictionary.com 을 통해 찾아 보았다 .

나쁜 이름으로 프로그래밍을 시작하는 것은 아침에 아주 나쁜 머리카락을 가진 것과 같으며, 나머지는 거기서 내리막 길을갑니다. 내 기분?

지금하고있는 일은 괜찮습니다. 현재 구문을 고수하는 것이 좋습니다.

문맥 + 동사 + 방법

이 방법을 사용하여 함수 / 메서드, SQL 저장 프로 시저 등의 이름을 지정합니다.이 구문을 유지하면 Intellisense / Code Panes가 훨씬 깔끔하게 유지됩니다. 따라서 EmployeeGetByID () EmployeeAdd (), EmployeeDeleteByID ()가 필요합니다. GetEmployee (), AddEmployee ()와 같이 문법적으로 올바른 구문을 사용하면 관련이없는 것과 같은 클래스에 여러 개의 Get이 그룹화되어 있으면 이것이 지저분해질 것입니다.

나는 날짜가있는 파일의 이름을 지정하는 것과 비슷합니다 .2009-01-07.log가 아니라 1-7-2009.log가 아니라고 말하면 순서가 완전히 쓸모 없게되기 때문입니다.

내가 배운 한 가지 교훈은 수업의 이름을 찾을 수 없으면 거의 항상 해당 수업에 문제가 있다는 것입니다.

• 당신은 필요하지 않습니다
• 너무 많아

적절한 명명 규칙은 주어진 변수, 클래스, 메소드 또는 함수에 사용할 수있는 이름의 수를 최소화해야합니다. 가능한 이름이 하나만 있으면 이름을 기억하는 데 어려움이 없습니다.

함수와 싱글턴 클래스의 경우 기본 함수가 한 종류의 것을 다른 종류의 것으로 변환하는 것인지 확인하기 위해 함수를 면밀히 조사합니다 . 나는 그 용어를 매우 느슨하게 사용하고 있지만, 당신이 작성하는 수많은 함수는 본질적으로 어떤 형태로 무언가를 취하고 다른 형태로 무언가를 생산한다는 것을 알게 될 것입니다.

귀하의 경우 클래스 가 Url을 문서로 변환 하는 것처럼 들립니다 . 그런 식으로 생각하는 것은 조금 이상하지만 완벽하게 맞습니다.이 패턴을 찾기 시작하면 어디서나 볼 수 있습니다.

이 패턴을 찾으면 항상 함수 이름을 x Fromy로 지정 합니다.

함수 가 URL을 문서로 변환 하므로 이름을 지정합니다.

DocumentFromUrl

이 패턴은 매우 일반적입니다. 예를 들면 다음과 같습니다.

atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine

당신이 UrlToDocument그 순서에 더 편한 경우 에도 사용할 수 있습니다 . 당신이 말하는 여부 의 X From, Y 또는 y를 Tox는 아마 취향의 문제이지만, 내가 선호 From하는 방법은 함수 이름의 시작은 이미 당신을 알려주기 때문에 순서가 반환 무엇을 입력합니다.

하나의 규칙을 선택하고 준수하십시오. x Fromy 함수 에서 클래스 이름과 동일한 이름을 사용하는 데주의를 기울이면 사용한 이름을 기억하기가 훨씬 쉽습니다. 물론이 패턴은 모든 것이 작동하지는 않지만 "기능적"이라고 생각할 수있는 코드를 작성하는 경우에는 작동합니다.

때로는 클래스 나 메소드의 이름이 좋지 않을 때 우리 모두에게 발생합니다. 그러나 종종 이름을 제시하지 못하면 디자인에 문제가있는 것일 수 있습니다. 분석법에 너무 많은 책임이 있습니까? 수업은 일관된 아이디어를 캡슐화합니까?

실 1 :

function programming_job(){
    while (i make classes){
         Give each class a name quickly; always fairly long and descriptive.
         Implement and test each class to see what they really are. 
         while (not satisfied){
            Re-visit each class and make small adjustments 
         }
    }
}

실 2 :

while(true){
      if (any code smells bad){
           rework, rename until at least somewhat better
      }
}

여기에는 Thread.sleep (...)이 없습니다.

프로그래밍 할 때 이름을 붙일 수있는 이름에 대해 많은 시간을 할애하고 있습니다. 나는 그것이 아주 잘 지불한다고 말하고 싶다. 때때로 내가 붙어있을 때 나는 잠시 동안 그것을 떠나 커피 휴식 시간 동안 누군가가 좋은 제안이 있는지 조금 물어보십시오.

당신의 수업에 대해 제안 VendorHelpDocRequester합니다.

Steve Mcconnell의 Code Complete 라는 책 에는 변수 / 클래스 / 함수 / 이름 지정에 대한 장이 있습니다.

나는 이것이 부작용이라고 생각합니다.

어려운 실제 이름이 아닙니다. 어려운 것은 이름을 짓는 과정에서 당신이 무엇을하고 있는지 전혀 모른다는 끔찍한 사실에 직면한다는 것입니다.

나는 어제 37Signals 의 Signal vs. Noise 블로그를 통해이 인용문을 들었 습니다.

"컴퓨터 과학에는 캐시 무효화와 이름 지정이라는 두 가지 어려운 점이 있습니다." — 필 칼튼

어려운 것이 좋습니다. 문제와 클래스가 실제로해야 할 일에 대해 생각하도록 강요합니다. 좋은 이름은 좋은 디자인으로 이어질 수 있습니다.

동의했다. 나는 타입 이름과 변수를 너무 끔찍하게 길지 않고 가능한 한 서술 적으로 유지하고 싶지만 때로는 좋은 단어를 찾을 수없는 특정 개념이 있습니다.

이 경우에는 항상 동료에게 입력을 요청하는 데 도움이됩니다. 궁극적으로 도움이되지 않더라도 적어도 설명을 크게하고 바퀴를 돌리도록 도와줍니다.

나는 지난 달에 명명 규칙에 글을 쓰고 있었다 : http://caseysoftware.com/blog/useful-naming-conventions

그것의 요지 :

verbAdjectiveNounStructure- 선택적 부품으로 구조 및 형용사 포함

들어 동사 , 나는 액션 동사에 충실 : 통보, 삭제, 저장, 업데이트 또는 생성합니다. 가끔은 "프로세스"를 사용하지만 대기열 또는 작업 백 로그를 구체적으로 참조하기 위해서만 사용합니다.

들어 명사 , 나는 클래스를 사용하거나 상호 작용되는 객체입니다. web2project에서 이것은 종종 작업 또는 프로젝트입니다. 페이지와 상호 작용하는 Javascript 인 경우 본문 또는 테이블 일 수 있습니다. 요점은 코드가 상호 작용하는 객체를 명확하게 설명한다는 것입니다.

구조 는 상황에 고유 때문에 선택 사항입니다. 목록 화면에서 목록 또는 배열을 요청할 수 있습니다. web2project의 프로젝트 목록에서 사용되는 핵심 기능 중 하나는 단순히 getProjectList입니다. 기본 데이터를 수정하지 않고 데이터 표현 만 수정합니다.

형용사는 완전히 다른 무언가이다. 명사에 대한 수정 자로 사용됩니다. getOpenProjects와 같이 간단한 것은 getProjects 및 switch 매개 변수를 사용하여 쉽게 구현할 수 있지만, 기본 데이터 및 / 또는 객체의 구조에 대해 약간의 이해가 필요한 메소드를 생성하는 경향이 있습니다. 북돋우다. 보다 명시적이고 구체적인 함수를 사용하면 구현을 코드에서 완전히 감싸서 숨길 수 있습니다. OO의 요점이 아닌가?

클래스의 이름을 지정하는 것 외에도 적절한 패키지 구조를 만드는 것은 어렵지만 보람있는 도전이 될 수 있습니다. 모듈의 문제와 모듈이 응용 프로그램의 비전과 어떻게 관련되어 있는지 분리해야합니다.

지금 앱의 레이아웃을 고려하십시오.

• 앱
  • VendorDocRequester (웹 서비스에서 읽고 데이터 제공)
  • VendorDocViewer (요청자를 사용하여 공급 업체 문서 제공)

나는 몇 수업 안에 많은 일들이 진행되고 있다고 추측하려고 노력했다. 이것을 MVC 기반 접근 방식으로 리팩토링하고 소규모 클래스가 개별 업무를 처리하도록 허용하면 다음과 같은 결과가 발생할 수 있습니다.

• 앱
  • VendorDocs
    • 모델
      • 문서 (데이터를 보유한 일반 객체)
      • WebServiceConsumer (웹 서비스에있어 뻔뻔스러운 거래)
    • 제어 장치
      • DatabaseAdapter (ORM 또는 기타 방법을 사용한 핸들 지속성)
      • WebServiceAdapter (Consumer를 활용하여 문서를 가져 와서 데이터베이스에 고정)
    • 전망
      • HelpViewer (DBAdapter를 사용하여 문서를 추출)

그런 다음 클래스 이름은 네임 스페이스를 사용하여 전체 컨텍스트를 제공합니다. 클래스 자체는 명시 적으로 말할 필요없이 응용 프로그램과 본질적으로 관련 될 수 있습니다. 결과적으로 클래스 이름이 더 간단하고 쉽게 정의 할 수 있습니다!

또 다른 중요한 제안 : 자신에게 유리한 입장을 취하고 Head First Design Patterns 사본을 선택하십시오. 응용 프로그램을 구성하고 더 나은 코드를 작성하는 데 도움이되는 환상적이고 읽기 쉬운 책입니다. 디자인 패턴을 이해하면 발생하는 많은 문제가 이미 해결되었으며 솔루션을 코드에 통합 할 수 있음을 이해하는 데 도움이됩니다.

레오 브로디 (Leo Brodie)는 자신의 저서 "Thinking Forth"에서 프로그래머에게 가장 어려운 과제는 이름을 잘 짓는 것이 었으며 가장 중요한 프로그래밍 도구는 동의어 사전이라고 언급했습니다.

http://thesaurus.reference.com/ 에서 동의어 사전을 사용해보십시오. .

그 외에도 헝가리어 표기법을 사용하지 말고 약어를 피하고 일관성을 유지하십시오.

최고의 소원.

한마디로 :
나는 좋은 이름이 중요하다는 데 동의하지만, 모든 비용으로 구현하기 전에 이름을 찾아야한다고 생각하지 않습니다.

물론 처음부터 좋은 이름을 갖는 것이 좋습니다. 그러나 2 분 안에 문제를 해결할 수 없다면 나중에 이름을 바꾸는 데 시간이 덜 걸리고 생산성 관점에서 올바른 선택입니다.

긴:
일반적으로 구현하기 전에 이름에 대해 너무 오래 생각할 가치가없는 경우가 많습니다. 클래스를 구현하면 이름을 "Foo"또는 "Dsnfdkgx"로 지정하고 구현하는 동안 클래스 이름을 지정해야합니다.

특히 Java + Eclipse를 사용하면 모든 클래스의 모든 참조를 신중하게 처리하고 이름 충돌 등을 경고하므로 이름을 바꾸는 것이 전혀 고통스럽지 않습니다. 클래스가 아직 버전 제어 저장소에 있지 않은 한 이름을 5 번 바꾸는 데 문제가 있다고 생각하지 마십시오.

기본적으로 리팩토링에 대해 어떻게 생각하는지에 대한 질문입니다. 개인적으로, 나는 팀원이 때때로 실행중인 시스템을 건드리지 않는다고 믿기 ​​때문에 팀 동료를 짜증나게하지만 그것을 좋아합니다 . 리팩토링 할 수있는 모든 것에서 이름 변경은 할 수있는 가장 해로운 일 중 하나입니다.

HelpDocumentServiceClient 종류의 한 입이나 HelpDocumentClient가 아닌 이유는 벤더가 중요하지 않다는 것입니다. 요점은 도움말 문서를 다루는 웹 서비스의 클라이언트입니다.

그리고 네 이름 지정은 어렵습니다.

해당 클래스에는 하나의 현명한 이름 만 있습니다.

HelpRequest

구현 세부 사항이 의미를 혼란스럽게하지 마십시오.

좋은 리팩토링 도구에 투자하십시오!

나는 기본 사항을 고수합니다 : VerbNoun (인수). 예 : GetDoc (docID).

화려할 필요는 없습니다. 당신이든 다른 사람이든 지금부터 일년 후에는 이해하기 쉽습니다.

나를 위해 메소드 또는 클래스 이름이 설명적이고 올바른 라이브러리에있는 길이는 중요하지 않습니다. API의 각 부분이 상주하는 위치를 기억해야 할 시대는 지났습니다.

Intelisense는 모든 주요 언어에 존재합니다. 따라서 타사 API를 사용할 때 '실제'문서를 사용하는 대신 문서에 인텔리전스를 사용하는 것을 좋아합니다.

이를 염두에두고 다음과 같은 메소드 이름을 작성하는 것이 좋습니다.

StevesPostOnMethodNames 긴 또는 짧은

길지만 그렇게. 요즘 누가 24 인치 화면을 사용하지 않습니까!

나는 이름이 예술이라는 것에 동의해야한다. 수업이 특정 "desigh 패턴"(공장 등)을 따르는 경우 조금 더 쉬워집니다.

이것이 코딩 표준을 갖추어야하는 이유 중 하나입니다. 표준을 갖는 것은 필요할 때 이름을 찾는 것을 돕는 경향이 있습니다. 그것은 당신의 마음이 다른 더 흥미로운 것들을 사용할 수 있도록 도와줍니다! (-:

가독성과 유지 관리 성을 돕기 위해 몇 가지 규칙을 따르는 Steve McConnell의 Code Complete ( Amazon 링크 ) 의 관련 장을 읽는 것이 좋습니다 .

HTH

건배,

롭

아니, 디버깅은 나에게 가장 어려운 일이다! :-)

DocumentFetcher? 상황이 없으면 말하기가 어렵습니다.

당신이 갈 때 수학자처럼 행동하고 당신의 영역에 대한 사전을 빌리거나 발명하는 데 도움이 될 수 있습니다 . 매번 철자를 쓰지 않고 개념 을 제안 하는 짧은 평범한 단어를 정 하십시오. 너무 자주 나는 약어로 바뀌는 긴 라틴어 문구를 보았으므로 어쨌든 약어에 대한 사전이 필요 합니다 .

문제를 설명하는 데 사용하는 언어는 변수, 메서드, 개체, 클래스 등에 사용해야하는 언어입니다. 느슨하게도 명사는 개체와 동사를 일치시킵니다. 문제를 설명하는 단어가 누락 된 경우 문제에 대한 완전한 이해 (사양)가 누락 된 것입니다.

이름 세트 중 하나만 선택하는 경우 시스템을 구축하는 데 사용하는 규칙에 따라 이름을 지정해야합니다. 이전 관례에 의해 밝혀지지 않은 새로운 자리에 오 셨다면,이 새로운 사건을 다루기 위해 (적절하게, 일관되게) 확장하기 위해 항상 노력할 가치가 있습니다.

의심스러운 경우 잠을 자고 다음 날 아침 가장 분명한 이름을 선택하십시오 :-)

언젠가 깨어나서 잘못되었다는 것을 알게되면 즉시 바꾸십시오.

폴

BTW : Document.fetch ()는 꽤 분명합니다.

지역 변수에서 가장 큰 어려움을 겪고 있습니다. 예를 들어 DocGetter 유형의 객체를 만들고 싶습니다. 그래서 그것이 DocGetter라는 것을 알고 있습니다. 다른 이름을 지정해야하는 이유는 무엇입니까? 나는 보통 dg (DocGetter의 경우) 또는 temp 또는 같은 것이 아닌 다른 이름을 부여합니다.

GoF 패턴뿐만 아니라 디자인 패턴도 공통 어휘를 제공하는 좋은 방법이며, 상황에 맞을 때마다 이름을 사용해야합니다. 이는 명명법에 익숙한 신규 이민자들이 아키텍처를 빠르게 이해하는 데 도움이 될 것입니다. 이 클래스는 프록시 또는 Façade처럼 행동해야합니까?

공급 업체 문서가 대상이 아니어야합니까? 내 말은, 프로그램의 일부에 대한 의인화 만이 아니라 유형적이라는 것을 의미합니다. 따라서 VendorDocumentation정보를 가져 오는 생성자 가있는 클래스가 있을 수 있습니다 . 클래스 이름에 동사가 포함되어 있으면 종종 무언가 잘못되었다고 생각합니다.

확실히 당신을 느낍니다. 그리고 나는 당신의 고통을 느낍니다. 내가 생각하는 모든 이름은 나에게 쓰레기처럼 보입니다. 그것은 매우 일반적인 것처럼 보이며 결국 내 이름에 약간의 감각과 창의성을 주입하여 그들이 묘사하는 것을 실제로 반영하는 방법을 배우고 싶습니다.

내가 가진 제안 중 하나는 동의어 사전을 참조하는 것입니다. Mac OS X와 ​​마찬가지로 Word에는 좋은 것이 있습니다. 그렇게하면 구름에서 머리를 내밀고 영감을주는 좋은 출발점이됩니다.

이름이 평신도 프로그래머에게 설명된다면 이름을 바꿀 필요가 없습니다.