메소드 이름에 연결을 사용하는 것이 나쁜 명명 규칙 인 이유는 무엇입니까? [닫은]

12

우리 팀에서는 몇 명의 소프트웨어 설계자와 긴밀히 협력하고 있습니다. 그들은 우리 프로젝트의 모든 디자인 결정을 승인하고 코드 검토 등을 수행합니다.

우리 프로젝트는 주로 Symfony 2 프레임 워크를 사용하여 PHP로 구현 된 백엔드 기능으로 구성됩니다. 따라서 구문, 코드, 명명 규칙 및 프로젝트 구조는 Java의 모양과 거의 동일하게 보입니다 (Symfony 2는 이러한 구조를 권장합니다). Java 관련 규칙이 가능한 경우에도 적용되기 때문에 이것을 언급하고 있습니다.

최근에, 그들은 내가 아주 이상한 찾을 수 있다는 것을 제안 : 모든 방법은 자신의 이름 등의 접속사가 있어야 getEntityOrNull, setValueOrException등

이러한 명명 규칙은 나에게 매우 잘못 느껴지지만 구체적으로 논란이되는 구체적인 주장이나 온라인 기사 / 페이지를 생각해 낼 수는 없습니다.

내가 생각해 낸 유일한 것은 :

이러한 정보는 @return또는@throws
분석법 이름에 연결 ( "및", "또는"등)을 사용하면 일반적으로 단일 책임 원칙이 제대로 준수되지 않음을 나타냅니다.

이 명명 규칙에 대한 다른 구체적인 주장은 무엇입니까?

php conventions naming-standards

— 라두 머 제아
소스

일반적으로, 당신은 할 수 없습니다

— 모기

5

the use of conjunctions ("and", "or" etc.) in method names usually suggest that the Single Responsibility Principle is not properly respected

나열된 예제의 경우에는 해당되지 않습니다. 여기서 연결은 실패를 처리하는 데 사용되는 메커니즘을 명확하게하는 데 사용되며 하나의 작업을 수행 할 수 있음을 나타내지 않습니다. 가장 좁게 정의 된 함수조차도 빈 스택을 터뜨리는 등의 합법적 인 실패 조건을 가질 수 있습니다.

— Doval

4

다음을 고려하십시오. (1) "또는 널"대신 "선택"을 사용하십시오. "GetOptionalEntity"가 "GetEntityOrNull"보다 귀에 더 좋습니다. (2) .NET 기본 클래스 라이브러리는 던지는 방식이 다른 두 개의 메서드가있는 경우 "TryBlah"를 던질 수없는 메서드의 이름을 지정하는 규칙을 사용합니다. 예를 들어, Int32.TryParse과 Int32.Parse- 모두 구문 분석 정수에 캐릭터지만, 전 반환 부울 성공을 나타내는 후자는 실패가 발생합니다.

— Eric Lippert

던지는 변형에는 접미사를 사용하지 않지만 null 반환 변형에는 접미사를 사용합니다. 될 수 있을까 Try..., ...OrNull, ...OrDefault. @EricLippert .net의 유일한 규칙은 아닙니다. 제안 된 OP에 매우 가까운 Singlevs.를 고려하십시오 . SingleOrDefaultOrNull

— 코드 InChaos

11

이름 충돌로 인해 아마도 그렇게하고 있습니다. 나는 당신이 이름을 가진 두 개의 메소드를 가질 수 없다고 가정한다 . getEntity하나는 예외를 던지고 다른 하나는 리턴한다 null. 따라서 그에 따라 이름을 지정해야합니다.

나는 특정 클래스 만 수행 할 수있는 변경을 수행하지 않는 한 동일한 방법을 호출하는 다양한 방법을 사용하는 것을 싫어한다.

즉, getValueOrNull단순히 호출 getValueOrException하는 경우 예외를 캡처 null하고이 경우를 반환하는 경우 호출자가이를 수행 할 수 있습니다. 실제로 유용한 것을 제공하지 않는 메소드로 클래스를 복잡하게 만듭니다. 오히려 나는을 선호 getValue하고 예외가 발생한다는 것을 알고 있습니다. 더 나은 방법으로, 모든 get 메소드가 잠재적으로 예외를 throw하고 그 중 어느 것도 리턴 null하지 않으므로 동작이 내 프로젝트 전체에서 균일하거나 반대로 잠재적으로 모두 리턴 null될 수 있고 호출자가 예외를 throw해야 함을 알고 싶습니다. 그것은 원했다.

그러나 귀하가 책임을지지 않는 것도 사실입니다. 내 충고는 그것을 제기하는 것이지만 사소한 것을 땀 내지 마십시오. 궁극적으로, 그러한 명명 규칙의 책임은 그들이 당신의 조언을 받는지 여부에 관계없이 어깨에 달려 있으며, 그것이 줄에 대한 그들의 엉덩이이기 때문에, 나는 겸손한 견해에서 아니오라고 말하는 것이 특권이라고 믿습니다.

— 닐
소스

하나만 선택해야한다면 null던지기 비용이 상대적으로 비싸기 때문에 반환 하는 것이 좋습니다. 값이 유효하지 않고 던지는 지 확인하는 도우미를 작성하면 많은 오버 헤드가 추가되지 않습니다. 그러나 던져지지 않는 버전을 원할 때 예외를 삼킨다 고해서 던져 버렸을 때의 성능 저하를 되 찾을 수는 없습니다.

— Doval

1

@Doval 좋은 점, 그리고 아마도 더 중요한 것은, 예외가되어야합니다 뛰어난 . 예외가 자주 발생하면 올바르게 사용하지 않는 것입니다. 반환 만 문제는 null즉 null당신이 규범에서 벗어나 이러한 경우에 예외를 throw 할 것이다, 그래서 실제로 어떤 경우에 유효한 반환하고 있습니다.

— 닐

3

연결의 사용은 종종 SRP의 위반을 나타내지 만,이 경우에는 두 가지 값 중 하나 null또는 "성공"값 중 하나 일 수있는 가난한 사람의 대수 데이터 형식의 반환 값을 나타내는 것입니다 .

그들은 유형 체계의 약점, 즉 널 입력 불가 유형의 부족을 보상하기 위해 일종의 헝가리 표기법 을 사용하고 있습니다. 다시 말해, @return어노테이션에서 함수가 절대 리턴 null하지 않도록 지정할 방법이없고 반대로 @return어노테이션에서 함수가 리턴 할 가능성 을 지정할 수있는 방법이 없습니다 null.

또한, @throwsPHP에서는 주석이 필수는 아니라고 생각하므로 주석이 없다는 것은 예외가 없음을 나타내지는 않지만 스타일 가이드에서 주석을 필수로 설정하면 더 잘 해결됩니다.

사용하는 언어에 대한 이러한 제한 사항을 고려할 때 완전히 부당한 스타일은 아닙니다.

— 칼 빌레펠트
소스

2

내 코드에서 때로는 getEntity () 및 getEntityOrNull ()과 같은 이름으로 메서드 쌍을 만듭니다. 이름은 예상되는 동작을 명확하게합니다. getEntity ()가 엔티티를 찾지 못하면 예외가 발생합니다. getEntityOrNull ()은 null을 반환합니다.

이렇게하면 호출 코드가 좀 더 명확 해집니다. 호출 코드에 엔티티가 있어야하는 경우 getEntity가 트릭을 수행합니다. entity가 일종의 선택적인 대상인 경우 getEntityOrNull이 선택 방법입니다.

단일 방법으로도 동일한 작업을 수행 할 수 있지만 이로 인해 일부 부담이 호출 프로그램으로 이동합니다. 항상 null을 테스트하거나 try / catch 블록이 필요합니다. 어느 쪽이든 메소드를 호출 할 때마다 복제해야하는 추가 코드입니다.

건축가가 이러한 종류의 메소드 쌍을 사용하지 않는다면 접미사가 필요한지 의문입니다.

실제로 setValueOrException 메소드를 본 적이 없습니다. 좋은 일반적인 사용 사례를 생각할 수 없습니다.

건축가에게 이유를 묻는 것을 고려할 수 있습니다. 내가 아는 사람들은 항상 그들의 결정을 설명하게되어 기쁘다. 종종 훌륭한 (그리고 때로는 끔찍한) 디테일.

— 세 라드
소스

getEntity가 실패하면 예외가 발생한다는 것이 전혀 명확하지 않습니다. 간단한 NULL을 기대할 것입니다.

— Elise van Looij

1

당신의 두 가지 주장은 건전합니다. 그러나 이들이 명명 규칙을 결정하는 책임을 가진 사람이라면, 동의하지 않는 것에 대해 너무 나쁘게 생각하지 마십시오.

이 방법을 사용하는 동안 해당 메소드가 실제로 직접 멤버 변수를 설정하거나 가져 오지 않는 한 "get"및 "set"부분을 사용하지 않도록 설득해야합니다.

— 에벤
소스