Node.js проект іменування файлів і папок


116

Які умови іменування файлів і папок у великому проекті Node.js?

Чи слід використовувати великі літери, camelCase чи недооцінку?

Тобто чи вважається це дійсним?

project-name
    app
        controllers
            someThings.js
            users.js
        models
                someThing.js
                user.js
        views
            some-things
                index.jade
            users
                logIn.jade
                signUp.jade
    ...

3
Високо суб'єктивна, структура вашого каталогу - ваша власна. Особисто мені подобається camelCase, тому що я роблю в JS
Чад

@Chad - у Node.js requireприймає рядок каталогів як параметр, тому це не зовсім ваше власне. тобто. require('../app/controllers/someThings');
Рудігер

3
Вузол не визначає жодних пропозицій чи стандартів щодо іменування модулів, до тих пір, поки вони є дійсними іменами файлів / каталогів і не намагаються замінити імена основних модулів . Для власних модулів він використовує суміш скорочених ( fs), однослівних ( events), підкреслених ( child_process) та малих літер ( querystring).
Джонатан Лоновський

1
@Rudiger Так? Ви можете вказати будь-який рядок, який хочете, і структуру каталогів, яку ви хочете мати (за умови, звичайно, що ваші імена є дійсними іменами файлів).
Чад

З того, що я можу сказати, замислюючись над більш ключовими проектами, такими як назви файлів mocha, як-от cap-awesome-file.js, здається, досить поширеними. Ось що я збираюся використати принаймні!
Чарльз Ферентчак

Відповіді:


154

Через кілька років з вузлом, я можу сказати , що не існує жодної конвенції для структури каталогів / файлів. Однак більшість (професійних) експрес-програм використовують такі налаштування:

/
  /bin - scripts, helpers, binaries
  /lib - your application
  /config - your configuration
  /public - your public files
  /test - your tests

Приклад, який використовує цю настройку, - nodejs-starter .

Я особисто змінив цю налаштування на:

/
  /etc - contains configuration
  /app - front-end javascript files
    /config - loads config
    /models - loads models
  /bin - helper scripts
  /lib - back-end express files
    /config - loads config to app.settings
    /models - loads mongoose models
    /routes - sets up app.get('..')...
  /srv - contains public files
  /usr - contains templates
  /test - contains test files

На мій погляд, останній краще відповідає структурі каталогу директорій у стилі Unix (тоді як перший трохи змішує це).

Мені також подобається, що цей візерунок розділяє файли:

lib / index.js

var http = require('http');
var express = require('express');

var app = express();

app.server = http.createServer(app);

require('./config')(app);

require('./models')(app);

require('./routes')(app);

app.server.listen(app.settings.port);

module.exports = app;

lib / static / index.js

var express = require('express');

module.exports = function(app) {

  app.use(express.static(app.settings.static.path));

};

Це дозволяє акуратно розв’язати весь вихідний код, не турбуючи залежності. Дійсно гарне рішення для боротьби з противними Javascript. Реальний приклад поруч , який використовує цю установку.

Оновлення (імена файлів):

Що стосується імен файлів, найпоширеніші - короткі , малі імена файлів. Якщо ваш файл можна описати лише двома словами, більшість проектів JavaScript використовують підкреслення як роздільник.

Оновлення (змінні):

Щодо змінних, то такі ж "правила" застосовуються, як і для імен файлів. Проте прототипи або класи повинні використовувати camelCase .

Оновлення (керівники стилів):


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

3
@ Tronix117 в чому проблема? Питання задає "Конвенції про іменування проектів для файлів і папок?" і іменування не обмежується іменем файлу, оскільки воно також включає повне ім'я шляху.
bodokaiser

24
Звичайно, але автор спеціально запитує "Чи слід писати великі літери, camelCase чи недооцінку?". Коли він пише свій приклад, він чітко вводить "деякі речі" та "деякі речі", просто щоб знати, чи можна вважати їх дійсним. Коли я перейшов до цієї теми, я сподівався відповісти на це конкретне запитання і знати, що зазвичай використовується як іменування файлів. Я не кажу, що ваша відповідь неправильна, вона ідеальна за своїм призначенням, але неповна на мою думку, оскільки він насправді не відповідає на головне питання.
Tronix117

5
Я думаю, ти мене неправильно зрозумів;). Я просто шукав те, чого не знайшов у прийнятій відповіді, але спеціально запитав, не поширюючи ненависті в будь-якому вигляді, ти йдеш трохи далеко за цим. Я просто хотів, щоб ви додали інформацію щодо цього у відповідь, щоб люди, які шукатимуть цього в майбутньому, не потраплять у тупик.
Tronix117

3
@ Tronix117 Власне, саме тому я опинився на цій сторінці, читаючи цю відповідь. Я сподівався на не лише структуру каталогів, але ще важливіше назвати конвенції (тире, підкреслення, camelCase, TitleCase тощо). На жаль, відповідь все ще не містить її, і, здається bodokaiser, я сприймаю речі надто особисто, щоб заскочити і просити, щоб його відповідь щодо цього була додана до його відповіді (як спочатку запитувала ОП у їхньому питанні) ( кашель від кашлю ).
Поворот

97

Використовувати kebab-caseдля всіх назв пакета, папки та файлів.

Чому?

Ви можете собі уявити, що будь-яку папку чи файл можна витягнути до власного пакета в якийсь день. Пакети не можуть містити великі літери.

Нові пакети не повинні мати великих літер у назві. https://docs.npmjs.com/files/package.json#name

Тому camelCaseніколи не слід використовувати. Це залишає snake_caseі kebab-case.

kebab-caseна сьогоднішній день є найбільш поширеною умовою сьогодні. Єдине використання підкреслення лише для внутрішніх пакетів вузлів, і це просто умова з перших днів.


2
ти забув крапку? як socket.io
Roee

1
.2c, може зробити просту автоматизацію від kebab-case до kebabCase в будь-якому сценарії чи програмі будь-якою мовою за допомогою regex - робіть це весь час 🙃
rob2d

63

Конвенцій немає. Є якась логічна структура.

Єдине, що я можу сказати: Ніколи не використовуйте назви файлів і каталогів camelCase. Чому? Він працює, але на Mac і Windows немає різниці між деякими діями та деякими діями. Я зустрів цю проблему, і не один раз. Мені потрібен такий файл:

var isHidden = require('./lib/isHidden');

Але , до жаль , я створив файл з повним малими літерами: lib/ishidden.js. Це працювало для мене на mac. Це добре спрацювало на mac мого колеги. Тести працюють без помилок. Після розгортання ми отримали величезну помилку:

Error: Cannot find module './lib/isHidden'

О так. Це linux box. Тож структура каталогів camelCase може бути небезпечною. Досить колезі, який розробляє Windows або Mac.

Тому використовуйте роздільник підкреслення (_) або тире (-), якщо вам потрібно.


4
+1, додайте той факт, що перейменування чутливих до регістру папок у git в системі, що не стосується cs, є справжнім клопотом.
макс

4
Я не дуже розумію тут проблему з camelCase. Не вдалося б вирішити проблему, назвавши файл в першу чергу правильно (lib / isHidden.js)?
Майк

Ей, Майку, справа в тому, що camelCase збирається вийти з ладу в деяких системах. Мене збентежило те, чому всі мої каталоги отримують 404-х, коли я розгортався з Mac на скриньку Linux з пакетом під назвою "groupPages". Мені довелося перейти на групові сторінки, щоб виправити речі.
tempranova

3
Що ще гірше: створіть верблюжкову версію імені файлу і недбайливий колега створить малу версію в тому самому каталозі. Тепер зробіть перевірку в незалежному від регістру ОС, і спробуйте з'ясувати, чому, до біса, ваша програма не працює. І так, це сталося.
L0LN1NJ4

Мені подобається ця відповідь, проте я хочу зазначити, що тире (-) теж може мати деякі проблеми. Наприклад, за допомогою тестової рамки Nighwatch я створив об’єкт сторінки під назвою admin-login.js. Потім я спробував отримати доступ до нього з тестового сценарію за допомогою const loginPage = browser.page.admin-login(). Я отримав помилку ReferenceError: login is not defined. Використання підкреслення (_) для імені файлу вирішило проблему. Я також можу уявити, що використання назви файлів з символом тире в командному рядку також може призвести до деяких проблем. Тому я б сказав, що підкреслення є найбезпечнішим роздільником імен файлів загалом.
Драган Ніколіч

15

На основі " Посібника зі стилю Google JavaScript "

Імена файлів мають бути малими літерами і можуть містити підкреслення (_) або тире (-), але без додаткових розділових знаків. Дотримуйтесь конвенції, яку використовує ваш проект. Розширення імен файлів повинно бути .js.


3

Більшість людей використовують camelCaseу JS. Якщо ви хочете щось відкрити, пропоную вам скористатися цим :-)


Деякі проекти, наприклад Locomotive.js, використовуються camelCaseдля файлів контролера. :-) Просто залежить. Я схильний використовувати PascalCaseдля файлів, схожих на клас.
Матьє Аміот

@yitsushi, схоже, викликає занепокоєння з приводу іменування верблюда (і паскаль), якщо ви хочете створити портативні модулі, корпус верблюда напевно здається поганою ідеєю?
gumaflux

0

Node.js не застосовує жодних умов іменування файлів (крім index.js). І мова Javascript взагалі теж не є. Тут ви можете знайти десятки ниток, які пропонують camelCase, дефіси та підкреслення, будь-яка з яких працює чудово. Тож саме від вас залежить. Виберіть один і дотримуйтесь його.


1
Це насправді не те, що вузол "примушує", будь ласка, прочитайте це: nodejs.org/api/modules.html#modules_folders_as_modules
moka

0

По-моєму: для файлів використовуйте нижній регістр верблюда, якщо module.exports є об'єктом, я маю на увазі однотонний модуль. Це також стосується файлів JSON, оскільки вони також є в тоні одним тоном. Використовуйте верхній регістр верблюда, якщо module.exports повертає функцію конструктора там, де він діє як клас.

Для папок використовуйте короткі імена. Якщо вам потрібно мати кілька слів, нехай це повністю нижній регістр розділяється на "-", щоб він працював на всіх платформах послідовно.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.