-[불필요한 맥락 제거하기](#불필요한-맥락-제거하기)

-[Use default arguments instead of short circuiting or conditionals](#use-default-arguments-instead-of-short-circuiting-or-conditionals)

-[**Functions**](#functions)

-[Function arguments (2 or fewer ideally)](#function-arguments-2-or-fewer-ideally)

-[함수 인자 (이상적으로는 2개 이하)](#함수-인자-이상적으로는-2개-이하)

-[**Classes**](#classes)

-[**Single Responsibility Principle (SRP)**](#single-responsibility-principle-srp)

-[**Open/Closed Principle (OCP)**](#openclosed-principle-ocp)

This is by far the most important rule in software engineering. When functions

do more than one thing, they are harder to compose, test, and reason about.

When you can isolate a function to just one action, they can be refactored

easily and your code will read much cleaner. If you take nothing else away from

this guide other than this, you'll be ahead of many developers.

소프트웨어 엔지니어링에서 가장 중요한 규칙입니다. 함수가 한가지 이상의 일을 수행한다면 함수를 구성, 테스트, 추론하기 어려워집니다. 함수를 한 가지 일만 수행하도록 분리한다면 쉽게 리팩토링 할 수 있으며, 코드는 더욱 깔끔해집니다. 이 가이드에서 이 한 가지만 기억하더라도 다른 많은 개발자보다 앞서게 될 것입니다.

**Bad:**

**나쁜 예:**

from typingimport List

email(client)

**Good**:

**좋은 예**:

from typingimport List

email(client)

from typingimport Generator, Iterator

**[⬆ back to top](#table-of-contents)**

A large amount of parameters is usually the sign that a function is

doing too much (has more than one responsibility). Try to decompose it

into smaller functions having a reduced set of parameters, ideally less than

three.

함수에 많은 파라미터가 있는 경우 함수가 너무 많은 작업 (하나 이상의 책임) 을 수행하고 있다는 신호일 수 있습니다. 이상적으로 2개 이하의 파라미터를 가지도록 함수를 분해해보세요.

If the function has a single responsibility, consider if you can bundle

some or all parameters into a specialized object that will be passed as an

argument to the function. These parameters might be attributes of a single

entity that you can represent with a dedicated data structure. You may also

be able to reuse this entity elsewhere in your program. The reason why this is

a better arrangement is than having multiple parameters is that we may be able

to move some computations, done with those parameters inside the

function, into methods belonging to the new object, therefore reducing the

complexity of the function.

만약 함수가 하나의 책임만을 가진다면, 일부 또는 모든 파라미터를 함수에 전달할 특수화된 객체로 묶어보는 것을 고려해보세요. 이러한 파라미터는 전용 데이터 구조로 표현될 수 있는 단일 엔티티의 애트리뷰트일 수 있습니다. 또한 이러한 엔티티는 다른 곳에서도 재사용할 수 있습니다. 여러 파라미터를 사용하는 것보다 이 방법이 나은 이유는 함수 내부에서 해당 파라미터로 수행되는 일부 계산을 새 엔티티에 속하는 메서드로 옮겨 함수의 복잡도를 줄일 수 있기 떄문입니다.

**Bad:**

**나쁜 예:**

defcreate_menu(title,body,button_text,cancellable):

**[⬆ back to top](#table-of-contents)**

**Bad:**

**나쁜 예:**

classEmail:

**[⬆ back to top](#table-of-contents)**

When you have more than one level of abstraction, your function is usually

doing too much. Splitting up functions leads to reusability and easier testing.

만약 하나 이상의 추상화 수준을 가진다면, 함수는 너무 많은 일을 할 수도 있습니다. 함수를 재사용 가능하고 테스트하기 쉽게 분리하세요.

**Bad:**

**나쁜 예:**

**Good:**

**좋은 예:**

from typingimport Tuple, List, Dict

**[⬆ back to top](#table-of-contents)**

Flags tell your user that this function does more than one thing. Functions

should do one thing. Split your functions if they are following different code

paths based on a boolean.

플래그는 사용자에게 함수가 한 가지 이상의 일을 한다는 것을 알려줍니다. 함수는 한가지 일만을 수행해야 합니다. 따라서 불리언 값에 따라 다른 코드 경로를 따르도록 함수를 분리하세요.

**Bad:**

**[⬆ back to top](#table-of-contents)**

A function produces a side effect if it does anything other than take a value

in and return another value or values. For example, a side effect could be

writing to a file, modifying some global variable, or accidentally wiring all

your money to a stranger.

함수가 입력값을 받아서 다른 값들을 반환하는 것 이외에 다른 작업을 수행하면 사이드 이펙트를 일으킵니다. 예를 들어, 파일 쓰기, 전역 변수 수정, 실수로 모르는 사람에게 돈을 송금하는 것 등이 있습니다.

Now, you do need to have side effects in a program on occasion - for example,

like in the previous example, you might need to write to a file. In these

cases, you should centralize and indicate where you are incorporating side

effects. Don't have several functions and classes that write to a particular

file - rather, have one

(and only one) service that does it.

프로그램에서 때때로 사이드 이펙트가 필요할 수 있습니다. 예를 들어, 이전 예와 같이 파일에 쓰기 작업이 필요할 수 있습니다. 이러한 경우에는 사이트 이펙트를 포함하는 위치를 중앙 집중화하고 표시해야 합니다. 특정 파일에 쓰기 작업을 하는 여러 함수와 클래스를 가지지 말고 하나의 서비스만을 가지세요.

The main point is to avoid common pitfalls like sharing state between objects

without any structure, using mutable data types that can be written to by

anything, or using an instance of a class, and not centralizing where your side

effects occur. If you can do this, you will be happier than the vast majority

of other programmers.

요점은 구조 없이 객체 간에 상태를 공유하거나, 누구나 쓸 수 있는 가변 데이터 유형을 사용하거나, 클래스의 인스턴스를 사용하거나, 부작용이 발생하는 위치를 중앙 집중화하지 않는 것과 같은 일반적인 함정을 피하는 것입니다. 이를 통해 대다수의 다른 프로그래머보다 행복하게 작업할 수 있을 것입니다.

**Bad:**

**나쁜 예:**

**Good:**

**좋은 예:**

from typingimport List, AnyStr