Как к лучшим полям имени и свойствам
Microsoft заявляет, что поля и свойства должны отличаться больше, чем просто случаем. Так, если они действительно представляют ту же идею, как они должны отличаться?
Вот пример Microsoft того, какой не сделать:
using System;
namespace NamingLibrary
{
public class Foo // IdentifiersShouldDifferByMoreThanCase
{
protected string bar;
public string Bar
{
get { return bar; }
}
}
}
Они не дают указаний на то, как это должно посмотреть. Что делает большинство разработчиков?
7 ответов
Нет, Microsoft заявляет публично видимые члены должны отличаться более чем просто регистром:
Это правило действует только на общедоступных членах.
(Это включает в себя защищенные члены, поскольку они видны производным классам.)
Так что все в порядке:
public class Foo
{
private string bar;
public string Bar { get { return bar; } }
}
Мое личное правило - в любом случае не разрешать какие-либо другие частные поля, и тогда это не проблема .
Вам действительно нужны защищенные поля? Как насчет того, чтобы сделать свойство защищенным установщиком, если вы хотите иметь возможность изменять его из производных классов?
Мне нравится:
protected string _Bar;
public string Bar
{
get { return _Bar; }
}
Думаю, большинство разработчиков префикс переменных-членов с подчеркиванием выглядит так:
protected string _bar;
Это может заставить некоторых разработчиков вскрикнуть от отвращения, но мне нравятся соглашения об именах, которые позволяют мне с первого взгляда отличить переменные-члены от локальных.
Поэтому я часто делаю что-то вроде:
public class Foo
{
protected string _bar;
public string Bar
{
get { return _bar; }
}
}
...или...
public class Foo
{
protected string mBar; // 'm' for member
public string Bar
{
get { return mBar; }
}
}
Это невозможно сделать. Интерфейсы, доступные для сценариев в PDF, чрезвычайно ограничены по сравнению с полным доступом к DOM и ведомостям материалов в веб-браузере. Такое взаимодействие, которого вы можете достичь в PDF, нелегко перевести из того, как оно работает в браузере, и почти наверняка потребуется ручная разработка.
Пример страницы имеет много эффектов, которые PDF, по существу статический формат макета документа, просто не может воспроизвести вообще.
Изменить:
Я просто хочу, чтобы окончательный рендеринг экрана был зафиксирован в PDF
Ah, OK, это гораздо проще и более распространенная проблема тогда.
В этом случае вам придется использовать и автоматизировать реальный веб-браузер (например, Firefox) или набор инструментов, обеспечивающий всю логику веб-браузера (например, WebKit), а затем:
экспортировать в PDF с помощью встроенных инструментов, таких как "Печать в файл" в Firefox (с включенными фоновыми изображениями/цветами) или одной из надстроек экспорта PDF, или
сделать снимок браузера (и включить изображение в PDF, если необходимо)
См. эти вопросы для обсуждения моментальных снимков браузера
-121--3425110- Я не знаю логику за ним, но локальные переменные не инициализируются как null . Думаю, чтобы облегчить тебе жизнь. Они могли бы сделать это с переменными класса, если бы это было возможно. Это не значит, что вы должны инициализировать его в начале. Это нормально:
MyClass cls;
if (condition) {
cls = something;
else
cls = something_else;
Я лично делаю следующее:
class SomeClass
{
private static string s_foo; // s_ prefix for static class fields
private string m_bar; // m_ prefix for instance class fields
public static string Foo
{
get { return s_foo; }
}
public string Bar
{
get { return m_bar; }
}
}
Я изначально использовал _ или m_ как префикс для всех своих полей, пока не начал копать много кода Microsoft .NET через Reflector. Microsoft также использует парадигму s_ и m_, и мне она вроде как нравится. Это упрощает точное определение поля при чтении кодового тела функции. Мне не нужно ничего указывать и ждать, пока появится подсказка или что-то подобное. Я знаю, является ли что-то статическим или экземпляром просто по префиксу поля.
Это зависит от вас или стандарта кодирования вашей компании\организации. Но большинство программистов используют camelCasing или подчеркивание + camelCasing для полей и PascalCasing для свойств, например:
public class Foo
{
protected string _bar;
public string Bar
{
get { return _bar; }
}
}