Должны папки в решении соответствовать пространству имен?
Исключение нулевого указателя генерируется, когда приложение пытается использовать null в случае, когда требуется объект. К ним относятся:
- Вызов метода экземпляра объекта
null. - Доступ или изменение поля объекта
null. - Принимая длину
null, как если бы это был массив. - Доступ или изменение слотов
null, как если бы это был массив. - Бросок
nullкак будто это было значение Throwable.
Приложения должны бросать экземпляры этого класса, чтобы указать на другие незаконные использования объекта null.
Ссылка: http://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html
5 ответов
Кроме того, обратите внимание, что при использовании встроенных шаблонов для добавления классов к папке, она будет по умолчанию помещена в пространство имен, которое отражает иерархию папок.
классы будет легче найти и что один должны быть достаточно хорошие причины.
правила, за которыми мы следуем:
- Проект/имя сборки совпадает с корневым пространством имен, за исключением .dll окончание
- , Только исключением к вышеупомянутому правилу является проект с окончанием.Core.Core разделяется прочь
- , Папки равняются пространствам имен
- , Один тип на файл (класс, структура, перечисление, делегат, и т.д.) облегчает находить правильный файл
Я думаю, что стандарт, в.NET, должен попытаться сделать это, если это возможно, но не создать излишне глубинные структуры только для соблюдения его как твердое правило. Ни один из моих проектов не следует за пространством имен == правило структуры 100% времени, иногда его просто более чистый/лучше для повреждения из таких правил.
В Java у Вас нет выбора. Я назвал бы это классическим случаем какой работы в теории по сравнению с какой работы на практике.
@lassevk: Я соглашаюсь с этими правилами и имею еще один для добавления.
, Когда я вложил классы, я все еще разделил их, один на файл. Как это:
// ----- Foo.cs
partial class Foo
{
// Foo implementation here
}
и
// ----- Foo.Bar.cs
partial class Foo
{
class Bar
{
// Foo.Bar implementation here
}
}
Я сказал бы да.
Первый, будет легче найти фактические файлы кода следующим вниз пространствами имен (скажите, когда кто-то посылает Вам по электронной почте явный стек вызовов исключения). Если Вы позволяете своим папкам выйти из синхронизации с пространствами имен, нахождение, что файлы в больших кодовых базах становятся получением утомительного.
112-секундный, VS генерирует новые классы, которые Вы создаете в папках с тем же пространством имен его родительской структуры папок. Если Вы решите плавать против этого, это будет просто еще одно задание инфраструктуры для делания ежедневно при добавлении новых файлов.
, Конечно, это само собой разумеется, что нужно быть консервативным о том, как глубокая иерархия папки/пространства имен кси идет.
Да они должны, только привести к беспорядку иначе.