diff --git a/README.md b/README.md index 53e196d..4602f01 100644 --- a/README.md +++ b/README.md @@ -3,10 +3,12 @@ [![Build Status](https://travis-ci.com/zedr/clean-code-python.svg?branch=master)](https://travis-ci.com/zedr/clean-code-python) [![](https://img.shields.io/badge/python-3.8+-blue.svg)](https://www.python.org/download/releases/3.8.3/) +Di-fork dari [clean-code-python](https://github.com/zedr/clean-code-python), dengan referensi penerjemahan dari [clean-code-javascript](https://github.com/andirkh/clean-code-javascript). + ## Table of Contents - 1. [Introduction](#introduction) - 2. [Variables](#variables) - 3. [Functions](#functions) + 1. [Kata Pengantar](#kata-pengantar) + 2. [Variabel](#variabel) + 3. [Fungsi](#fungsi) 4. [Objects and Data Structures](#objects-and-data-structures) 5. [Classes](#classes) 1. [S: Single Responsibility Principle (SRP)](#single-responsibility-principle-srp) @@ -16,25 +18,32 @@ 5. [D: Dependency Inversion Principle (DIP)](#dependency-inversion-principle-dip) 6. [Don"t repeat yourself (DRY)](#dont-repeat-yourself-dry) -## Introduction +## Kata Pengantar +![Gambar lucu dari estimasi kualitas perangkat lunak sebagai hitungan berapa +banyak umpatan yang keluar saat membaca kode](http://www.osnews.com/images/comics/wtfm.jpg) -Software engineering principles, from Robert C. Martin"s book -[*Clean Code*](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882), -adapted for Python. This is not a style guide. It"s a guide to producing -readable, reusable, and refactorable software in Python. -Not every principle herein has to be strictly followed, and even fewer will be universally -agreed upon. These are guidelines and nothing more, but they are ones codified over many -years of collective experience by the authors of *Clean Code*. +Prinsip Rekayasa Perangkat Lunak, oleh Robert C. Buku +[*Clean Code*](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) oleh Martin, +diadaptasi untuk Python. Perlu diingat bahwa panduan ini bukan tentang gaya +penulisan kode. Panduan ini lebih tentang membuat perangkat lunak yg [mudah dibaca, +dapat digunakan kembali, dan mudah direfaktor kembali](https://github.com/ryanmcdermott/3rs-of-software-architecture) +dalam bahasa Python. -Inspired from [clean-code-javascript](https://github.com/ryanmcdermott/clean-code-javascript) -Targets Python3.7+ +Tidak semua prinsip disini harus diikuti secara ketat, dan bahkan lebih sedikit +akan lebih mudah disepakati bersama. Ini hanyalah panduan-panduan saja dan tidak +lebih, tetapi panduan-panduan ini dikodifikiasi selama bertahun-tahun dari +pengalaman kolektif penulis buku *Clean Code*. -## **Variables** -### Use meaningful and pronounceable variable names +Terinspirasi dari [clean-code-javascript](https://github.com/ryanmcdermott/clean-code-javascript) -**Bad:** +Untuk Python3.7+ + +## **Variabel** +### Gunakan nama-nama variabel yang bermakna dan mudah diucapkan + +**Buruk:** ```python import datetime @@ -42,34 +51,34 @@ import datetime ymdstr = datetime.date.today().strftime("%y-%m-%d") ``` -**Good**: +**Baik**: ```python import datetime current_date: str = datetime.date.today().strftime("%y-%m-%d") ``` -**[⬆ back to top](#table-of-contents)** +**[⬆ kembali ke atas](#table-of-contents)** -### Use the same vocabulary for the same type of variable +### Gunakan kosakata yang sama untuk jenis variabel yang sama -**Bad:** -Here we use three different names for the same underlying entity: +**Buruk:** +Di sini kita menggunakan tiga nama berbeda untuk entitas dasar yang sama: ```python def get_user_info(): pass def get_client_data(): pass def get_customer_record(): pass ``` -**Good**: -If the entity is the same, you should be consistent in referring to it in your functions: +**Baik**: +Jika entitasnya sama, Anda harus menggunakan rujukan yang konsisten dalam fungsi Anda: ```python def get_user_info(): pass def get_user_data(): pass def get_user_record(): pass ``` -**Even better** +**Lebih Baik:** Python is (also) an object oriented programming language. If it makes sense, package the functions together with the concrete implementation of the entity in your code, as instance attributes, property methods, or methods: @@ -95,22 +104,22 @@ class User: **[⬆ back to top](#table-of-contents)** -### Use searchable names -We will read more code than we will ever write. It"s important that the code we do write is -readable and searchable. By *not* naming variables that end up being meaningful for -understanding our program, we hurt our readers. -Make your names searchable. +### Gunakan nama yg mudah dicari kembali +Kita akan lebih banyak membaca kode daripada menulisnya. Maka penting hukumnya +menulis kode untuk mudah dibaca dan mudah dicari. Dengan *tidak* memberi nama +variabel yang bermakna untuk memahami program kita, kita menyakiti pembaca kode +kita. Buat nama variabel lebih mudah dicari. -**Bad:** +**Buruk:** ```python import time -# What is the number 86400 for again? +# Angka 86400 itu untuk apa? time.sleep(86400) ``` -**Good**: +**Baik**: ```python import time @@ -121,8 +130,8 @@ time.sleep(SECONDS_IN_A_DAY) ``` **[⬆ back to top](#table-of-contents)** -### Use explanatory variables -**Bad:** +### Gunakan variabel penjelas +**Buruk:** ```python import re @@ -135,9 +144,9 @@ if matches: print(f"{matches[1]}: {matches[2]}") ``` -**Not bad**: +**Tidak buruk**: -It"s better, but we are still heavily dependent on regex. +Ini lebih baik, tapi kita masih sangat bergantung pada regex. ```python import re @@ -152,9 +161,9 @@ if matches: print(f"{city}: {zip_code}") ``` -**Good**: +**Baik**: -Decrease dependence on regex by naming subpatterns. +Kurangi ketergantungan pada regex dengan memberi nama pada subpola. ```python import re @@ -168,11 +177,11 @@ if matches: ``` **[⬆ back to top](#table-of-contents)** -### Avoid Mental Mapping -Don’t force the reader of your code to translate what the variable means. -Explicit is better than implicit. +### Hindari Mental Mapping +Jangan paksa pembaca kode Anda untuk menerjemahkan arti dari sebuah variabel. +Eksplisit lebih baik daripada implisit. -**Bad:** +**Buruk:** ```python seq = ("Austin", "New York", "San Francisco") @@ -180,11 +189,11 @@ for item in seq: #do_stuff() #do_some_other_stuff() - # Wait, what's `item` again? + # Sebentar, `item` itu untuk apa tadi? print(item) ``` -**Good**: +**Baik**: ```python locations = ("Austin", "New York", "San Francisco") @@ -197,12 +206,12 @@ for location in locations: **[⬆ back to top](#table-of-contents)** -### Don"t add unneeded context +### Jangan menambahkan konteks yang tidak dibutuhkan -If your class/object name tells you something, don"t repeat that in your -variable name. +Jika nama class/objek kamu memiliki arti tertentu, jangan mengulanginya di dalam +nama variabel. -**Bad:** +**Buruk:** ```python class Car: @@ -211,7 +220,7 @@ class Car: car_color: str ``` -**Good**: +**Baik**: ```python class Car: @@ -222,11 +231,11 @@ class Car: **[⬆ back to top](#table-of-contents)** -### Use default arguments instead of short circuiting or conditionals +### Gunakan argumen default daripada `short circuiting` dan `kondisional` -**Tricky** +**Rumit** -Why write: +Kenapa menulis: ```python import hashlib @@ -238,10 +247,9 @@ def create_micro_brewery(name): # etc. ``` -... when you can specify a default argument instead? This also makes it clear that -you are expecting a string as the argument. +... padahal Anda bisa menentukan argumen default? Ini juga menjelaskan bahwa Anda mengharapkan string sebagai nilai argumennya. -**Good**: +**Baik**: ```python from typing import Text @@ -254,7 +262,7 @@ def create_micro_brewery(name: Text = "Hipster Brew Co."): ``` **[⬆ back to top](#table-of-contents)** -## **Functions** +## **Fungsi** ### Function arguments (2 or fewer ideally) Limiting the amount of function parameters is incredibly important because it makes testing your function easier. Having more than three leads to a combinatorial explosion