Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitbba92da

Browse files
committed
replace " by ' in words like don"t, remove trailing spaces
1 parent9191067 commitbba92da

File tree

1 file changed

+31
-32
lines changed

1 file changed

+31
-32
lines changed

‎README.md‎

Lines changed: 31 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -14,17 +14,17 @@
1414
3.[L: Liskov Substitution Principle (LSP)](#liskov-substitution-principle-lsp)
1515
4.[I: Interface Segregation Principle (ISP)](#interface-segregation-principle-isp)
1616
5.[D: Dependency Inversion Principle (DIP)](#dependency-inversion-principle-dip)
17-
6.[Don"t repeat yourself (DRY)](#dont-repeat-yourself-dry)
17+
6.[Don't repeat yourself (DRY)](#dont-repeat-yourself-dry)
1818

1919
##Introduction
2020

21-
Software engineering principles, from Robert C. Martin"s book
21+
Software engineering principles, from Robert C. Martin's book
2222
[*Clean Code*](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882),
23-
adapted for Python. This is not a style guide. It"s a guide to producing
23+
adapted for Python. This is not a style guide. It's a guide to producing
2424
readable, reusable, and refactorable software in Python.
2525

26-
Not every principle herein has to be strictly followed, and even fewer will be universally
27-
agreed upon. These are guidelines and nothing more, but they are ones codified over many
26+
Not every principle herein has to be strictly followed, and even fewer will be universally
27+
agreed upon. These are guidelines and nothing more, but they are ones codified over many
2828
years of collective experience by the authors of*Clean Code*.
2929

3030
Inspired from[clean-code-javascript](https://github.com/ryanmcdermott/clean-code-javascript)
@@ -90,14 +90,13 @@ class User:
9090

9191
defget_record(self) -> Union[Record,None]:
9292
return Record()
93-
9493
```
9594

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

9897
###Use searchable names
99-
We will read more code than we will ever write. It"s important that the code we do write is
100-
readable and searchable. By*not* naming variables that end up being meaningful for
98+
We will read more code than we will ever write. It's important that the code we do write is
99+
readable and searchable. By*not* naming variables that end up being meaningful for
101100
understanding our program, we hurt our readers.
102101
Make your names searchable.
103102

@@ -137,7 +136,7 @@ if matches:
137136

138137
**Not bad**:
139138

140-
It"s better, but we are still heavily dependent on regex.
139+
It's better, but we are still heavily dependent on regex.
141140

142141
```python
143142
import re
@@ -197,9 +196,9 @@ for location in locations:
197196
**[⬆ back to top](#table-of-contents)**
198197

199198

200-
###Don"t add unneeded context
199+
###Don't add unneeded context
201200

202-
If your class/object name tells you something, don"t repeat that in your
201+
If your class/object name tells you something, don't repeat that in your
203202
variable name.
204203

205204
**Bad:**
@@ -256,13 +255,13 @@ def create_micro_brewery(name: Text = "Hipster Brew Co."):
256255
**[⬆ back to top](#table-of-contents)**
257256
##**Functions**
258257
###Function arguments (2 or fewer ideally)
259-
Limiting the amount of function parameters is incredibly important because it makes
260-
testing your function easier. Having more than three leads to a combinatorial explosion
258+
Limiting the amount of function parameters is incredibly important because it makes
259+
testing your function easier. Having more than three leads to a combinatorial explosion
261260
where you have to test tons of different cases with each separate argument.
262261

263-
Zero arguments is the ideal case. One or two arguments is ok, and three should be avoided.
264-
Anything more than that should be consolidated. Usually, if you have more than two
265-
arguments then your function is trying to do too much. In cases where it"s not, most
262+
Zero arguments is the ideal case. One or two arguments is ok, and three should be avoided.
263+
Anything more than that should be consolidated. Usually, if you have more than two
264+
arguments then your function is trying to do too much. In cases where it's not, most
266265
of the time a higher-level object will suffice as an argument.
267266

268267
**Bad:**
@@ -422,7 +421,7 @@ def create_menu(config: MenuConfig):
422421
create_menu(
423422
# You need to supply all the parameters
424423
MenuConfig(
425-
title="My delicious menu",
424+
title="My delicious menu",
426425
body="A description of the various items on the menu",
427426
button_text="Order now!",
428427
cancellable=True
@@ -432,10 +431,10 @@ create_menu(
432431
**[⬆ back to top](#table-of-contents)**
433432

434433
###Functions should do one thing
435-
This is by far the most important rule in software engineering. When functions do more
436-
than one thing, they are harder to compose, test, and reason about. When you can isolate
437-
a function to just one action, they can be refactored easily and your code will read much
438-
cleaner. If you take nothing else away from this guide other than this, you"ll be ahead
434+
This is by far the most important rule in software engineering. When functions do more
435+
than one thing, they are harder to compose, test, and reason about. When you can isolate
436+
a function to just one action, they can be refactored easily and your code will read much
437+
cleaner. If you take nothing else away from this guide other than this, you'll be ahead
439438
of many developers.
440439

441440
**Bad:**
@@ -544,7 +543,7 @@ message.send()
544543

545544
###Functions should only be one level of abstraction
546545

547-
When you have more than one level of abstraction, your function is usually doing too
546+
When you have more than one level of abstraction, your function is usually doing too
548547
much. Splitting up functions leads to reusability and easier testing.
549548

550549
**Bad:**
@@ -610,10 +609,10 @@ def parse(tokens: List) -> List:
610609

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

613-
###Don"t use flags as function parameters
612+
###Don't use flags as function parameters
614613

615-
Flags tell your user that this function does more than one thing. Functions
616-
should do one thing. Split your functions if they are following different code
614+
Flags tell your user that this function does more than one thing. Functions
615+
should do one thing. Split your functions if they are following different code
617616
paths based on a boolean.
618617

619618
**Bad:**
@@ -651,14 +650,14 @@ def create_temp_file(name: Text) -> None:
651650

652651
###Avoid side effects
653652

654-
A function produces a side effect if it does anything other than take a value in
655-
and return another value or values. For example, a side effect could be writing
653+
A function produces a side effect if it does anything other than take a value in
654+
and return another value or values. For example, a side effect could be writing
656655
to a file, modifying some global variable, or accidentally wiring all your money
657656
to a stranger.
658657

659658
Now, you do need to have side effects in a program on occasion - for example, like
660659
in the previous example, you might need to write to a file. In these cases, you
661-
should centralize and indicate where you are incorporating side effects. Don"t have
660+
should centralize and indicate where you are incorporating side effects. Don't have
662661
several functions and classes that write to a particular file - rather, have one
663662
(and only one) service that does it.
664663

@@ -673,7 +672,7 @@ If you can do this, you will be happier than the vast majority of other programm
673672
#type:ignore
674673

675674
# This is a module-level name.
676-
# It"s good practice to define these as immutable values, such as a string.
675+
# It's good practice to define these as immutable values, such as a string.
677676
# However...
678677
fullname="Ryan McDermott"
679678

@@ -686,7 +685,7 @@ def split_into_first_and_last_name() -> None:
686685

687686
split_into_first_and_last_name()
688687

689-
# MyPy will spot the problem, complaining about 'Incompatible types in
688+
# MyPy will spot the problem, complaining about 'Incompatible types in
690689
# assignment: (expression has type "List[str]", variable has type "str")'
691690
print(fullname)# ["Ryan", "McDermott"]
692691

@@ -720,7 +719,7 @@ class Person:
720719

721720
@property
722721
defname_as_first_and_last(self) ->list:
723-
returnself.name.split()
722+
returnself.name.split()
724723

725724

726725
# The reason why we create instances of classes is to manage state!
@@ -749,7 +748,7 @@ print(person.name_as_first_and_last) # => ["Ryan", "McDermott"]
749748

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

752-
##**Don"t repeat yourself (DRY)**
751+
##**Don't repeat yourself (DRY)**
753752

754753
*Coming soon*
755754

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp