Règle

Une classe par dossier.
Plusieurs classes dans a fichier fichier faire code
organisation peu claire et plus plus navigation.

Langues prises en charge : 45+

Introduction

Le fait de placer plusieurs classes dans un seul fichier rend difficile la localisation de classes spécifiques lorsque l'on navigue dans une base de code. Les développeurs qui recherchent des Référentiel d'utilisateurs ne le trouvera pas rapidement s'il est enfoui dans un fichier nommé database.js avec cinq autres classes. Cela viole le principe de moindre surprise et ralentit le développement, car les membres de l'équipe perdent du temps à rechercher les définitions des classes.

Pourquoi c'est important

Maintenabilité du code : La multiplicité des classes par fichier crée des frontières floues entre les responsabilités. Lorsqu'une classe doit être modifiée, les développeurs doivent ouvrir un fichier contenant des classes sans rapport, ce qui augmente la charge cognitive et le risque de modifier accidentellement un code erroné.

Navigation et découverte : Les IDE et les éditeurs de texte peinent à fournir des définitions précises lorsque plusieurs classes partagent un même fichier. Les développeurs perdent du temps à chercher dans les fichiers plutôt que d'accéder directement à la classe dont ils ont besoin. Cette situation s'aggrave dans les grandes bases de code comportant des centaines de classes.

Conflits de contrôle de version : Lorsque plusieurs classes partagent un fichier, les modifications apportées à différentes classes par différents développeurs créent des conflits de fusion. Les fichiers séparés permettent un développement parallèle sans frais de coordination, puisque chaque développeur travaille dans son propre fichier.

Exemples de code

❌ Non conforme :

// database.js
class UserRepository {
    async findById(id) {
        return db.users.findOne({ id });
    }
}

class OrderRepository {
    async findByUser(userId) {
        return db.orders.find({ userId });
    }
}

class ProductRepository {
    async findInStock() {
        return db.products.find({ stock: { $gt: 0 } });
    }
}

module.exports = { UserRepository, OrderRepository, ProductRepository };

Pourquoi c'est mal : Trois classes de référentiel sans rapport entre elles dans un seul fichier nommé database.js. Recherche de Référentiel de commande nécessite de savoir qu'il est dans database.js plutôt que OrderRepository.js. Les modifications de fichiers affectent plusieurs classes, ce qui crée des conflits de fusion inutiles.

✅ Conforme :

// UserRepository.js
class UserRepository {
    async findById(id) {
        return db.users.findOne({ id });
    }
}
module.exports = UserRepository;

// OrderRepository.js
class OrderRepository {
    async findByUser(userId) {
        return db.orders.find({ userId });
    }
}
module.exports = OrderRepository;

// ProductRepository.js
class ProductRepository {
    async findInStock() {
        return db.products.find({ stock: { $gt: 0 } });
    }
}
module.exports = ProductRepository;

Pourquoi cela est-il important ? Chaque classe dans son propre fichier rend la navigation prévisible. Les IDE peuvent passer directement à OrderRepository.js lors de la recherche de la classe. Les modifications apportées à un référentiel n'affectent pas les autres, ce qui élimine les conflits de fusion inutiles.

Conclusion

Nommez les fichiers d'après la classe qu'ils contiennent pour une navigation prévisible. Cette convention s'applique à de grandes bases de code où il est important de trouver rapidement des classes spécifiques. Les fichiers supplémentaires valent la peine pour la clarté organisationnelle qu'ils apportent.