명명 규칙, 코드 규칙

"안녕, 아미고! 오늘은 코드 스타일과 코드 스타일의 중요성에 대해 알려줄게."

"가장 중요한 것부터 시작하겠습니다.  Java 코드는 읽기 쉬워야 합니다.  코드에 대한 일반적인 접근 방식은 다음과 같습니다. 코드는 한 번 작성되지만 백 번 읽습니다."

"당신과 10명의 다른 프로그래머가 응용 프로그램을 작성한다고 가정합니다. 당신은 3개월마다 중간 릴리스를 포함하여 3년 동안 응용 프로그램 작업을 합니다."

"그렇게 오래?"

"이것이 바로 내 어린 베짱이 자바! "100명이 6년 넘게 쓰고 수십 대의 서버에서 실행되는 엔터프라이즈 시스템은 어떻습니까? 그것도 가끔 일어난다."

"워."

"어쨌든 주요 규칙, 코드에 대한 주요 요구 사항은 다른 개발자가 쉽게 읽을 수 있어야 한다는 것입니다."

"다른 프로그래밍 언어에서는 사람들이 작은 작업에 대해 소규모 팀으로 작업하는 경우가 많기 때문에 '작동합니까? 훌륭합니다'와 같은 또 다른 주요 규칙이 있을 수 있습니다."

"몇 년 동안 모든 팀원은 당신이 작성한 코드를 여러 번 변경할 것입니다. 그리고 매번 코드가 어떻게 작동하는지 이해해야 합니다."

"그리고 완벽하게 작동하는 이해할 수 없는 코드는 변경하기 어렵습니다.  그들은 그것을 버리고 자신의 방식으로 다시 작성할 것입니다.  따라서 다른 사람들이 이해할 수 있는 코드를 작성하십시오.  코드를 개선할 수 있으면 개선하십시오. 개선할 수 있는 경우 그럼 개선해야지! "

"15분 동안 코드를 작성한 다음 코드를 개선하는 데 2시간을 소비한다면 제대로 하고 있는 것입니다. 얼마나 많은 시간을 팀을 절약하고 있습니까?"

"'코드를 이해하는 데 2시간' x '사람들이 코드를 이해해야 하는 100번' = 200시간."

"나는 이 수치를 허공에서 꺼냈지만 문제와 그 범위를 이해하기를 바랍니다.  당신의 코드는 다른 프로그래머가 읽을 수 있도록 만들어졌습니다.  다른 모든 것은 부차적입니다."

"코드가 올바르게 작동하지 않습니까? 수정하겠습니다. 최적화되지 않았습니까? 최적화하겠습니다. 문서화되지 않았습니까? 주석을 추가하겠습니다."

" 코드가 읽기 어려우세요? 쓰레기는 쓰레기통에 버리고 처음부터 다시 작성하세요! "

"그렇게 큰 일이라고 생각하지 않았습니다."

"Java가 최고의 프로그래밍 언어인 이유 중 하나는 모든 Java 코드가 다른 프로그래머가 읽을 수 있도록 작성되었기 때문입니다."

"이제 두 번째 질문으로 넘어가겠습니다. 코드를 최대한 읽기 쉽게 만드는 방법은 무엇입니까? "

"누군가 모국어로 익숙한 단어를 말하면 누구나 이해할 수 있습니다. 여기도 마찬가지입니다. 프로그래머가 쉽게 추측할 수 있을 때 코드를 쉽게 읽을 수 있습니다.

A)  각 방법이 하는 일

나)  각 수업의 목적

C)  각 변수가 정확히 무엇을 저장하는지.

이 모든 것은 클래스 이름, 메서드 이름 및 변수 이름과 같은 이름으로 전달됩니다. 또한 변수 이름 지정과 관련하여 스타일이 있습니다. 그리고 코드 스타일이 있습니다."

"들을 준비가 되었습니다."

" 프로그래밍은 좋은 영어가 기본!  잘 작성된 프로그램은 일반 기술 문서처럼 읽힙니다. "

" 이름부터 시작합시다. "

"메소드 이름은 메소드가 수행하는 작업을 간략하게 설명해야 합니다. 그러면 코드를 간단한 산문처럼 읽을 수 있습니다."

public String downloadPhoto(String url)
{
 String resultFileName = TempHelper.createTempFileName();

 Downloader downloader = new SingleFileDownloader(new Url(url));
 downloader.setResultFileName(resultFileName)
 downloader.start();
 while(downloader.isDone())
 {
  Thread.sleep(1000);
 }

 if (downloader.hasError())
  return null;

 return resultFileName;
}

"그런 프로그램을 읽는 방법은 다음과 같습니다."

라인 1.

"이 방법은 'downloadPhoto'라고 합니다. 인터넷에서 사진 파일을 다운로드하는 것 같습니다. 어디로 다운로드합니까? 아직 모릅니다. 어디에서? 이 방법에는 url이라는 매개 변수가 있습니다. 아마도 URL일 것입니다. 다운로드."

3행.

"변수 resultFileName은 TempHelper.createTempFileName()에 의해 선언되고 값이 할당됩니다."

따라서 이것은 다운로드한 파일을 저장할 파일의 로컬 경로여야 합니다.

"'TempHelper'라는 이름은 우리에게 아무 의미가 없습니다. 'Helper' 접미사는 이것이 중요한 비즈니스 로직을 포함하지 않는 일종의 유틸리티 클래스라고 말하지만, 오히려 자주 발생하는 일상적인 작업을 단순화하는 데 사용됩니다."

"메소드 이름 'createTempFileName'은 이 메서드가 임시 파일(임시 파일)의 이름을 생성하고 반환함을 나타냅니다. 임시 파일은 잠시 동안 생성된 다음 일반적으로 프로그램이 닫힐 때 삭제되는 임시 파일입니다. "

5행.

"SingleFileDownloader 객체가 생성되어 변수 다운로더에 할당됩니다."

이것은 인터넷에서 파일을 다운로드할 개체입니다.

"SingleFileDownloader 개체는 가변 다운로더에 할당됩니다. 이름에서 프로그램에 여러 유형의 다운로더 클래스가 있다고 가정할 수 있습니다. 하나는 단일 파일을 다운로드하기 위해 작성되었으며 그룹용 코드에서 다른 다운로더를 만날 수 있을 것으로 예상할 수 있습니다. MultiFileDownloader, FileGroupDownloader 또는 DirectoryDownloader와 같은 이름을 가진 파일"

6행.

"우리는 다운로더 개체의 resultFileName 속성을 변수 resultFileName의 값과 동일하게 설정했습니다. 즉, 로더에게 다운로드한 파일을 저장할 위치를 알려줍니다. 예상한 대로입니다. 따라서 기본적으로 코드를 예측하고 있습니다!"

7행.

"우리는 시작 방법을 호출합니다. 다운로드가 시작됩니다. 말이 됩니다. 다운로드가 어떻게 발생하는지 궁금합니다. 부분적으로, 별도의 스레드에서 또는 전체를 바로 여기에서 다운로드할 수 있습니다. 오랜 시간이 걸리고 결과가 있습니다."

8-11행.

"아. 여기에서 다운로드가 완료되기를 기다리는 누군가가 작성한 표준 루프를 볼 수 있습니다. downloder 개체에는 isDone() 메서드에 의해 반환되는 done 속성이 있습니다. 이 메서드는 getDone(이 아니라 isDone()이라고 합니다. ), done 변수가 부울 또는 아마도 부울이라는 결론을 내립니다."

13-14행.

"다운로드 중에 오류가 발생하면 downloadPhoto 메서드는 null을 반환합니다. 오류를 처리하는 것은 좋습니다. null만 반환하는 것은 좋지 않습니다. 오류가 무엇인지 명확하지 않습니다. 다음에 대한 정보와 함께 예외를 throw하는 것이 좋습니다. 오류."

16행.

"다운로드한 파일이 포함된 로컬 파일의 경로를 반환합니다."

"워!"

"이 프로그램의 코드는 그것이 무엇을 하는지 절대적으로 명확하게 만듭니다. 프로그램이 어떻게 구성되어 있고 우리가 찾을 다른 클래스/메서드에 대해 추측할 수도 있습니다."

"이제 이름이 얼마나 중요한지 이해합니다."

"이름에 대해 자세히 알아보십시오. 개체/클래스에 어떤 메서드가 있는지 추측할 수 있습니다. 예를 들어 개체가 컬렉션인 경우 요소 수를 가져오는 size() 또는 count() 메서드가 있을 가능성이 큽니다. 또한 , 아마도 add() 또는 insert() 메서드가 있을 것입니다. 요소는 get/getItem/getElement 메서드를 사용하여 컬렉션 클래스에서 검색됩니다."

"변수가 i, j 또는 k라고 하면 루프 카운터일 가능성이 큽니다."

"변수가 m 또는 n이면 배열/컬렉션의 크기일 가능성이 큽니다."

"변수가 이름이라고 하면 누군가의 이름을 포함하는 문자열일 가능성이 큽니다."

"클래스가 FileInputStream인 경우 파일인 동시에 입력 스트림입니다."

"더 많은 코드를 볼수록 다른 사람의 코드를 더 쉽게 읽을 수 있습니다."

"하지만 때때로 읽기 매우 어려운 코드가 있습니다. 이 경우 매우 실용적인 조언이 있습니다."

"그것은 재미있으면서도 동시에 웃기지 않습니다."

"이제 변수 이름 지정에 사용되는 스타일에 대해 조금 알아보겠습니다."

"Java 개발자는 변수와 메서드에 매우 유용한 이름을 지정하려고 합니다. 결과적으로 이름은 종종 여러 단어로 구성됩니다. 복합 이름의 대문자 표시에는 4가지 스타일이 있습니다."

1) 소문자  – 모든 단어는 소문자로 쓴다. 예를 들어:

'온실'은 '온실'이  됩니다

'할리우드 걸'은 '할리우드 걸'  이 된다 

이 스타일은 패키지 이름에 사용됩니다.

2) 대문자  – 모든 단어는 대문자로 작성되고 밑줄로 구분됩니다. 예를 들어:

'최대값'이 MAX_VALUE  가 됨

'고양이 수'는 CAT_COUNT  가 됩니다.

"이 스타일은 상수(최종 정적 필드)의 이름에 사용됩니다."

3) CamelCase  – 각 단어의 첫 글자가 대문자인 경우를 제외하고 모든 단어는 소문자로 작성됩니다. 예를 들어:

'온실'은 '온실'  이 됩니다 

'할리우드 걸'은 '할리우드 걸'  이 된다

이 스타일은 클래스 및 인터페이스의 이름에 사용됩니다.

4) Lower CamelCase (혼합 케이스)  – 모든 단어는 소문자로 작성되며, 각 단어의 첫 글자는 대문자로 제외됩니다. 예를 들어:

'너비 가져오기' 는 'getWidth' 가 됩니다

'Get Hollywood girl name' 은 'getHollywoodGirlName' 이 됩니다 

"이 스타일은 변수 및 메소드의 이름에 사용됩니다."

"그래서 규칙이 너무 많지 않습니다."

1)  모든 것은 Lower CamelCase로 작성됩니다.

2)  클래스 및 인터페이스의 이름은 항상 대문자를 사용합니다.

3)  패키지 이름은 항상 소문자입니다.

4)  상수는 항상 대문자입니다.

"몇 가지 뉘앙스가 있지만 일반적으로 그게 전부입니다."

"이제 방법에 대해.  "방법 이름은 거의 항상 동사로 시작합니다! 'count'는 메소드의 나쁜 이름입니다. getCount()라고 부르는 것이 좋습니다. 메서드는 개체에 대해 몇 가지 작업을 수행합니다:  startDownload , interrupt  , sleep  , loadPirateMusic ."

"이미 알고 있듯이 개체의 속성/필드 작업을 위한 getter 및 setter가 있습니다:  getName / setName , getCount / setCount 등."

"유일한 예외는 부울입니다. 부울의 경우 getter 이름은 'get'이 아니라 'is'를 사용합니다. 예를 들어 isDone, isEmpty입니다. 이렇게 하면 일반 음성에 더 가깝습니다."

"하루 8시간 대신 2시간 일하는 건 어때? 유혹?"

"예!"

"그렇게 해야 합니다. 주니어 Java 개발자의 기본 요구 사항은 Java, 즉 Java Core의 기본 사항에 대한 탁월한 이해입니다."

"또 다른 질문이 있습니다. 요소 수를 가져오는 데 이렇게 다른 방법이 있는 이유는 무엇입니까?"

"우선, Java는 setCount / getCount 와 같은 요구 사항 이 확립되기 전인 20년 이상 전에 발명되었으며 C 언어에서 '가능한 한 짧게 만들기'라는 일반적인 접근 방식이 있었습니다."

"두 번째로 여기서 의미론이 중요한 역할을 합니다. 배열에 대해 이야기할 때 우리는 배열의 길이에 대해 이야기합니다. 컬렉션에 대해 이야기할 때 우리는 크기에 대해 이야기합니다."

"재미있는 수업이군요."

"자세히 말씀드리고 싶은데 한번에 다 기억나지 않으실까봐 걱정입니다. 조금씩 나눠서 드리는게 낫습니다."

"하지만 중괄호 사용과 관련된 스타일을 다루고 싶습니다: {}. 두 가지 접근 방식이 있습니다."

1)  괄호는 매번 새로운 줄로 이동합니다.

2)  여는 괄호는 이전 줄의 끝으로 가고 닫는 괄호는 새 줄로 갑니다. 이 스타일을 '이집트 교정기'라고 합니다.

"솔직히 코딩 방법을 선택해야 합니다. 많은 사람들이 같은 줄에 여는 중괄호를 사용합니다. 많은 사람들이 새 줄에 넣습니다. 계란의 어느 쪽 끝을 깨뜨릴 것인지에 대한 논쟁과 같습니다: 작은 끝 또는 큰 끝 끝."

"내가 추천할 수 있는 유일한 것은 작업 중인 프로젝트에서 사용 중인 스타일을 고수하는 것입니다. 선호하는 스타일에 맞게 다른 사람의 코드를 변경하지 마십시오.  사람들은 불완전합니다. 이것을 Bilaabo 박사에게 말하고 있습니다. "

"흥미로운 수업 감사합니다, Bilaabo. 당신이 말한 것을 반성하러 가겠습니다."