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

Placer plusieurs classes dans un seul fichier rend difficile la localisation de classes spécifiques lors de la navigation dans une base de code. Les développeurs recherchant UserRepository ne le trouvera pas rapidement s'il est enfoui dans un fichier nommé database.js aux côtés de 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 de classes.

Pourquoi c'est important

Maintenabilité du code : Plusieurs classes par fichier créent 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 non liées, ce qui augmente la charge cognitive et le risque de modifier accidentellement le mauvais code.

Navigation et découvrabilité : Les IDE et les éditeurs de texte ont du mal à fournir une fonction "aller à la définition" précise lorsque plusieurs classes partagent un fichier. Les développeurs passent du temps à chercher dans les fichiers plutôt qu'à sauter directement à la classe dont ils ont besoin. Cela se complique dans les grandes bases de code avec 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. Des fichiers séparés permettent un développement parallèle sans surcharge de coordination, car 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 incorrect : Trois classes de référentiels non liées dans un fichier nommé database.js. Recherche de OrderRepository nécessite de savoir que c'est dans database.js plutôt que OrderRepository.js. Les modifications de fichiers affectent plusieurs classes, créant 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 c'est important : Chaque classe dans son propre fichier rend la navigation prévisible. Les IDE peuvent sauter directement vers OrderRepository.js lors de la recherche de la classe. Les modifications apportées à un dépôt n'affectent pas les autres, éliminant ainsi les conflits de fusion inutiles.

Conclusion

Nommez les fichiers d'après la classe qu'ils contiennent pour une navigation prévisible. Cette convention est adaptée aux grandes bases de code où la recherche rapide de classes spécifiques est cruciale. Les fichiers supplémentaires valent la clarté organisationnelle qu'ils apportent.