Деякі найкращі практики для використання у коді! Algocool

практики

Для початку написання читабельного вихідного коду - одна з найкращих практик, яку повинен знати будь-який хороший розробник. Я не збираюся детально тут деталізувати, оскільки про це вже є стаття. Просто знайте, що наявність чистого вихідного коду легко читається багато переваг, навіть якщо для цього потрібно трохи більше подумати. Є й інші, не обов'язково обов'язкові, але які допомагають уникнути деяких помилок! Ходімо !

Необов’язкові брекети

У більшості мов фігурні дужки не є обов’язковими для деяких операторів, коли є лише один рядок, наприклад if, while або for. Щоб звільнити місце, спокусливо видалити фігурні дужки:

Але припустимо, що в якийсь момент ви додаєте додатковий рядок до умови, це виглядає так:

На жаль, забув додати брекети, як у мене крутиться голова! Очевидно, що це помилка, яка трапляється, коли ви не приділяєте достатньо уваги, але просто відсутність фігурної дужки може стати джерелом помилок пізніше. Тож ми могли б також переконатися, що їх ніколи не буде систематично ставлячи брекети ! І, чесно кажучи, я роблю помилку, постійно забуваючи брекети, тому постійно їх надягаю !

Зрештою, фігурні дужки не є такими необов’язковими, оскільки помилки, які вони можуть спричинити, вони не є. !

Передача іменованих параметрів

Передача параметрів у функцію зазвичай здійснюється за позицією. Порядок, у якому вони були визначені у функції, впливає на те, в яку позицію надсилати параметр. Якщо змінна розміру оголошена в першій позиції, тоді ви повинні надіслати їй значення, що відповідає цій позиції під час виклику:

Але що, як випадково поміняю місцями дві цифри (просто тому, що я не обережний, так), і біса! Функція працює не так, як очікувалося! З іншого боку, якщо я подбаю про те, щоб назвати параметри функції:

Більше необережності, і вихідний код виграє у читабельності як бонус !

Присвоєння аргументів виправляє потенційні джерела помилок, оскільки порядок параметрів більше не враховується. З іншого боку, лише деякі мови дають можливість це робити. Наприклад, JAVA, PHP або C ++ не дозволяють цього порівняно з C # або Objective C.

Уникайте дублювання

Ну, перші 2 були частиною найкращих практик, щоб уникнути дрібних необережних помилок, ця набагато важливіша. Дублювання коду, він же ctrl-c/ctrl-v, значно збільшує читабельність, обслуговування та продуктивність вихідного коду.

Краще зробити це:

Так що так, вам потрібно написати додаткову функцію. Але що, якщо я хочу внести зміни до елементів списку, змінивши стиль «Список» на «Елемент»? У першому прикладі я міняю 5 рядків, у другому тільки один ! І я навіть не кажу про випадки, коли є більше 10 повторень !

Більше того, якщо я хочу додати додаткові елементи, мені просто потрібно змінити параметр, просто і швидко !Якщо у вас є можливість спростити свій код виявляючи та видаляючи дублікати, не поспішайте це робити, але робіть це! Час, який ви витрачаєте на чистоту, заощадить час на технічне обслуговування та усунення несправностей. !

Ще одне занепокоєння, яке викликає дублювання, полягає в тому, що ви копіюєте та вставляєте фрагмент коду в іншу частину програми, код якої для нього не підходить. Ця проблема полягає у відомій копії/вставці анти-шаблону 😎 щоб якомога більше уникати, якщо у вас є можливість використовувати метод вилучення, віддайте перевагу його копіюванню та вставленню, або краще, використовуйте функцію та уникайте дублювання !

Тут ми бачимо, що я зробив функцію displayListList простою копією та вставкою displayList. Але я зробив це, не змінюючи змінну $ elements циклу, це буде невеликою проблемою:-(.

Скажете мені, це чергова необережна помилка! Але якщо подумати, це те, що представляє більшість помилок програмування. І крім того, я роблю повторення коду за допомогою циклу! Код, який уникає повторень, буде виглядати приблизно так:

Набагато складніше, але це частина найкращих практик, які слід застосувати 🙂

Скрізь оптимізація !

Все починається з хорошого принципу, бажаючи надмірно ефективного коду. Але проблема в тому, що оптимізувати програмне забезпечення, яке не працює, трохи безглуздо. Код повинен бути на 100% функціональним, чистим і читабельним, перш ніж думати про будь-яку оптимізацію. Слід уникати оптимізації, яка має на меті отримати 0,001 секунди продуктивності проти 3 годин роботи.

Будьте обережні, це теж не повинно бути приводом писати щось важке. Якщо функція використовує алгоритм обробки зі складністю O (n²), і це може зробити краще з O (n), ви повинні використовувати найбільш ефективний, навіть якщо його реалізація є більш складною. Це складно, ви повинні знати, як зважити всі за і проти під час написання оптимізованого коду. Про це потрібно подумати ще до того, як розробити програму. Визначте важку обробку та подумайте про код, який був би найбільш підходящим.

Помилка - марно витрачати час і чіткість у вихідному коді чогось, що насправді не варто. Яскравим прикладом поганої оптимізації є зміна мови програмування, хоча проект ще не закінчений, лише щоб зайняти кілька секунд продуктивності. Приріст незначний порівняно з часом, який знадобився б.

Спочатку змусьте це працювати, а потім зробіть це правильно

Інкапсуляція даних

Фундаментальний принцип об'єктно-орієнтованого програмування, кожен об’єкт повинен мати свої дані та методи. Те, як працює клас, не цікавить інших класів та інших користувачів. Крім того, всі атрибути класу повинні бути приватними або захищеними. Вони повинні забезпечувати спеціальні методи, які називаються accessors, що дозволяють доступ до цих атрибутів.

Неправильне, що потрібно зробити, це мати змінні, доступні по всьому коду, особливо якщо вони можуть змінити поведінку об’єкта. І ні, хоча це закономірність, Сінглтон не замінює глобальні змінні.

Висновок

  • Поставте брекети, навіть якщо це необов’язково
  • Назвіть аргументи під час виклику функції або методу, якщо це можливо
  • Уникайте повторень у коді та взагалі копіюйте та вставляйте.
  • Не оптимізуйте свій код відразу! Робіть щось, що працює і спочатку чисто
  • Зверніть увагу на сферу застосування атрибутів, внутрішня робота класу повинна бути прихованою.
  • Під час розробки регулярно тестуйте свій код, робіть невеликі кроки, але неодмінно рухайтеся вперед !
  • Подумайте модуль! Для кожної нової функції, яку ви робите, створюйте функції, які працюють абсолютно незалежно від оточення !
  • Мати читабельний вихідний код !
  • Начитаність вихідного коду має перевагу над іншими правилами ! Якщо ви застосовуєте одну з найкращих практик на шкоду читабельності, не робіть цього !

Завдяки цим передовим практикам ви готові створити якісний код !