SOFTWAREENGINEERVLOG Telegram 2295
Forwarded from S0ER.Code
Всегда ли короткие имена переменных - зло?

Никто не будет спорить с тем, что имена переменных в коде должны быть понятными и выразительными. Но с тем, что выразительное имя - это всегда полное длинное описание из которого можно сделать вывод для чего существует та или иная переменная - это тема для спора.

Я люблю короткие имена переменных, люблю аббревиатуры, часто их использую и мне не нравится писать длинные имена по типу "encodedDataBasePasswordStr", даже с автокомплитом.

Поэтому давайте сформулирую свои правила в отношении коротких имен переменных.

👑 Когда короткие имена приемлемы

В небольших методах с очевидным контекстом

В математических вычислениях, где традиционно используются короткие обозначения

Для итераторов в небольших циклах

В лямбда-функциях, где контекст ясен

Пример оправданного короткого имени.


function calculateDistance(x1: number, y1: number, x2: number, y2: number): number {
const dx = x2 - x1;
const dy = y2 - y1;
return Math.sqrt(dx * dx + dy * dy);
}

В этом случае:

x1, y1, x2, y2 - стандартные математические обозначения координат

dx, dy - общепринятые сокращения для "delta x" и "delta y"

А типы параметров (number) делают назначение переменных ещё понятнее

👑 Когда короткие имена недопустимы

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

В больших методах, где контекст теряется

Для переменных с широкой областью видимости

Когда назначение переменной неочевидно

Для булевых флагов, где важно понимать критерий

Пример плохого использования:


function processUserData(u: User, d: DataProcessor, c: Config) {
// ... 50 строк кода ...
if (u.s) { // Что такое 's'? Статус? Субscription? Счёт?
d.p(u); // Что делает 'p'? process? print? persist?
}
}

При этом вместо 'u' вполне можно было использовать сокращения usr, а вместо 'c' использовать cfg, это устоявшиеся сокращения, поэтому использовать их можно.

Когда есть возможность аннатировать переменную ее типом, с учетом небольшого размера функции, нормальным становится и вариант с u:


interface User {
id: string;
name: string;
age: number;
}

// Хорошо - тип ясен из контекста
function greet(u: User) {
console.log(`Hello, ${u.name}!`);
}


Для итераторов в небольших циклах короткие имена допустимы:



const numbers = [1, 2, 3];
// i - общепринятое имя для индекса
for (let i = 0; i < numbers.length; i++) {
console.log(numbers[i]);
}


В функциональном программировании для простых операций:



const users = [{name: 'Alice'}, {name: 'Bob'}];
// n - понятно в контексте map
const names = users.map(u => u.name);


👑 Надеюсь, приведенные пример убедили вас, что в зависимости от ситуации короткие имена переменных не только допустимы, но и помогают писать выразительный код.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6814🤣742👀2



tgoop.com/softwareengineervlog/2295
Create:
Last Update:

Всегда ли короткие имена переменных - зло?

Никто не будет спорить с тем, что имена переменных в коде должны быть понятными и выразительными. Но с тем, что выразительное имя - это всегда полное длинное описание из которого можно сделать вывод для чего существует та или иная переменная - это тема для спора.

Я люблю короткие имена переменных, люблю аббревиатуры, часто их использую и мне не нравится писать длинные имена по типу "encodedDataBasePasswordStr", даже с автокомплитом.

Поэтому давайте сформулирую свои правила в отношении коротких имен переменных.

👑 Когда короткие имена приемлемы

В небольших методах с очевидным контекстом

В математических вычислениях, где традиционно используются короткие обозначения

Для итераторов в небольших циклах

В лямбда-функциях, где контекст ясен

Пример оправданного короткого имени.


function calculateDistance(x1: number, y1: number, x2: number, y2: number): number {
const dx = x2 - x1;
const dy = y2 - y1;
return Math.sqrt(dx * dx + dy * dy);
}

В этом случае:

x1, y1, x2, y2 - стандартные математические обозначения координат

dx, dy - общепринятые сокращения для "delta x" и "delta y"

А типы параметров (number) делают назначение переменных ещё понятнее

👑 Когда короткие имена недопустимы

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

В больших методах, где контекст теряется

Для переменных с широкой областью видимости

Когда назначение переменной неочевидно

Для булевых флагов, где важно понимать критерий

Пример плохого использования:


function processUserData(u: User, d: DataProcessor, c: Config) {
// ... 50 строк кода ...
if (u.s) { // Что такое 's'? Статус? Субscription? Счёт?
d.p(u); // Что делает 'p'? process? print? persist?
}
}

При этом вместо 'u' вполне можно было использовать сокращения usr, а вместо 'c' использовать cfg, это устоявшиеся сокращения, поэтому использовать их можно.

Когда есть возможность аннатировать переменную ее типом, с учетом небольшого размера функции, нормальным становится и вариант с u:


interface User {
id: string;
name: string;
age: number;
}

// Хорошо - тип ясен из контекста
function greet(u: User) {
console.log(`Hello, ${u.name}!`);
}


Для итераторов в небольших циклах короткие имена допустимы:



const numbers = [1, 2, 3];
// i - общепринятое имя для индекса
for (let i = 0; i < numbers.length; i++) {
console.log(numbers[i]);
}


В функциональном программировании для простых операций:



const users = [{name: 'Alice'}, {name: 'Bob'}];
// n - понятно в контексте map
const names = users.map(u => u.name);


👑 Надеюсь, приведенные пример убедили вас, что в зависимости от ситуации короткие имена переменных не только допустимы, но и помогают писать выразительный код.

BY S0ER


Share with your friend now:
tgoop.com/softwareengineervlog/2295

View MORE
Open in Telegram


Telegram News

Date: |

Avoid compound hashtags that consist of several words. If you have a hashtag like #marketingnewsinusa, split it into smaller hashtags: “#marketing, #news, #usa. Concise Clear With Bitcoin down 30% in the past week, some crypto traders have taken to Telegram to “voice” their feelings.
from us


Telegram S0ER
FROM American