Действительно ли это - плохая практика, чтобы иметь несколько классов в том же файле?

Это может быть плохо с точки зрения будущей разработки и пригодности для обслуживания. Намного легче помнить, где Автомобильный класс - то, если у Вас есть класс Car.cs. Где Вы искали бы класс Виджета, если Widget.cs не существует? Действительно ли это - автомобильный виджет? Действительно ли это - виджет механизма? О, возможно, это - виджет рогалика.

Если Вы работаете над командой, остающиеся классы в отдельных файлах облегчают управлять источником, и уменьшает возможности конфликтов (несколько разработчиков, изменяющих тот же файл одновременно). Я думаю, что это облегчает находить код, который Вы ищете также.

Я нашел, что каждый раз, когда я пытаюсь объединить несколько типов в единственный файл, я всегда заканчиваю возвращение и разделение их просто, потому что это делает их легче найти. Каждый раз, когда я объединяюсь, существует всегда в конечном счете момент, где я пытаюсь выяснить wtf, я определил тип x

Поэтому теперь, мое персональное правило состоит в том, что каждый отдельный тип (кроме, возможно, для дочерних классов, который среднее класс в классе, не наследованном классе) получает свой собственный файл.

Один класс на файл является хорошим правилом, но уместно сделать некоторые исключения. Например, если я буду работать в проекте, где большинство классов связало типы набора, часто я буду сохранять класс и его набор в том же файле, например:

public class Customer { /* whatever */ }

public class CustomerCollection : List<Customer> { /* whatever */ }

лучшее эмпирическое правило должно сохранить один класс на файл кроме тех случаев, когда это начинает делать вещи тяжелее, а не легче. Так как Находка Visual Studio в Файлах является настолько эффективной, Вы, вероятно, не должны будете проводить много времени, просматривая файловую структуру так или иначе.

В Java один общественность класс на файл является способом, которым работает язык. Группа файлов Java может быть собрана в пакет.

В Python, однако, файлы являются "модулями", и обычно имеют много тесно связанных классов. Пакет Python является каталогом, точно так же, как пакет Java.

Это дает Python дополнительный уровень группировки между классом и пакетом.

нет никакого правильного ответа, который является агностиком языка. Это меняется в зависимости от языка.

Правило я всегда прохожу, состоит в том, чтобы иметь один основной класс в файле с тем же именем. Я могу или не могу включать классы помощника в тот файл в зависимости от того, как плотно они вместе с основным классом файла. Действительно ли классы поддержки автономны, или действительно ли они полезны самостоятельно? Например, если для метода в классе нужно специальное сравнение для сортировки некоторых объектов, это не беспокоит меня немного для связывания класса функтора сравнения в тот же файл как метод, который использует его. Я не ожидал бы использовать его в другом месте, и не имеет смысла для него быть самостоятельно.

Нет, я не думаю, что это совершенно плохая практика. То, что я имею в виду, в целом лучше иметь отдельный файл на класс, но определенно есть хорошие случаи исключений, где лучше иметь кучу классов в одном файле. Хорошим примером этого является группа классов исключений, если у вас есть несколько десятка из них для данной группы, это действительно имеет смысл иметь отдельную отдельную файл для каждого двухклассных классов? Я бы не спорил. В этом случае имея группу исключений в одном классе гораздо менее громоздким и простым ИМХО.

Ответ SmallTalk: у вас не должно быть файлов (для программирования). Они делают версию и навигацию болезненным.