C # штраф за количество строк кода?

Question

Существуют ли ограничения или ограничения производительности для количества кода в моей форме home.cs?

Я пишу интерфейс приложения базы данных на C # в Visual Studio 2008. В порядке вещей я использую способ отображения информации на вкладках для конечных пользователей вместо использования новых форм.

Исходя из VBA / MS Access, я помню, что если вы пройдете определенное количество строк кода, это приведет к ошибке и не скомпилируется. Будет ли C # делать это в Visual Studio 2008 или я пострадаю от снижения производительности? Я знаю, что читаемость кода может быть проблемой, потому что все будет в одном месте, но я также вижу это как преимущество в некоторых ситуациях.

Answer 1

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

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

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

Answer 2

Единственная проблема, которую я предвидел, состоит в том, что в будущем ее будет очень сложно поддерживать.

Попробуйте разбить логику этой главной формы как можно больше на классы, чтобы, когда вам нужно что-то добавить, вы могли сделать это без подгонки.

Answer 3

«Я знаю, что читаемость кода может быть проблемой, потому что все будет в одном месте, но я также вижу это как преимущество в некоторых ситуациях».

По моему опыту, такое отношение в конечном итоге оставит любого, кому придется поддерживать ваш код в будущем, с достаточно большой головной болью, так как это общепринятая практика модульного кодирования, чтобы части, которые могут измениться, или части, которые служат отчетливо отличающимся цели отделены друг от друга.

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

Я хотел бы призвать вас сохранить свое будущее и его / ее здравомыслие и логически разбить ваш код на отдельные файлы. Вы поблагодарите себя позже!

Answer 4

Если вы используете вкладки, вы все равно можете создавать пользовательские элементы управления, в которых будет храниться содержимое вкладок. Создайте элемент управления для каждой вкладки, и тогда вы сможете хранить код для разных вкладок отдельно. Здесь есть пошаговое руководство по MSDN здесь .

В ответ на ваш комментарий выше о том, что не показывать вкладки, я бы по-настоящему подумал, как вы к этому подходите. Почему бы просто не разместить все свои пользовательские элементы управления в главной форме, если это необходимо, на Panel, чтобы все они были установлены на Dock = DockStyle.Fill, а затем изменить свойства Visible и Enabled в зависимости от того, какой из них вы хотите показать? Возможно, вы делаете это для себя сложнее, чем нужно.

Больше ответов на комментарии - Возможно, вы ищете что-то вроде CardLayout на Java. Источник для версии GNU Classpath можно найти здесь , он может дать вам некоторые идеи о том, как это реализовать.

Answer 5

Это не должно быть проблемой.

Просто помните о хороших методах кодирования и модульности своего кода для удобочитаемости и удобства обслуживания.

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

Answer 6

У меня есть форма, унаследованная от моей новой работы, которая имела более 30 000 строк. Это полностью злокачественная. Пожалуйста, подумайте, прежде чем кодировать и модульно!

Answer 7

Звучит ужасно, но я не вижу причин, по которым это может быть проблемой.