Именование Ваших проектов: это имеет значение?
Еще один результат ответа Збиля. Это немного легче изменить для меня - мне просто нужно настроить sz0, sz1 ..., а также убедиться, что маска # и loc # верны в блоках Set / Get.
Производительность мудрый, он должен быть таким же, как они оба решили 38 заявлений MSIL. (константы разрешаются во время компиляции)
public struct MyStruct
{
internal uint raw;
const int sz0 = 4, loc0 = 0, mask0 = ((1 << sz0) - 1) << loc0;
const int sz1 = 4, loc1 = loc0 + sz0, mask1 = ((1 << sz1) - 1) << loc1;
const int sz2 = 4, loc2 = loc1 + sz1, mask2 = ((1 << sz2) - 1) << loc2;
const int sz3 = 4, loc3 = loc2 + sz2, mask3 = ((1 << sz3) - 1) << loc3;
public uint Item0
{
get { return (uint)(raw & mask0) >> loc0; }
set { raw = (uint)(raw & ~mask0 | (value << loc0) & mask0); }
}
public uint Item1
{
get { return (uint)(raw & mask1) >> loc1; }
set { raw = (uint)(raw & ~mask1 | (value << loc1) & mask1); }
}
public uint Item2
{
get { return (uint)(raw & mask2) >> loc2; }
set { raw = (uint)(raw & ~mask2 | (value << loc2) & mask2); }
}
public uint Item3
{
get { return (uint)((raw & mask3) >> loc3); }
set { raw = (uint)(raw & ~mask3 | (value << loc3) & mask3); }
}
}
13 ответов
Я думаю, называя, важная часть получения идей распространиться. Что я ищу на имя:
- Незабываемый. Это должно отличаться, чем другие имена, но должно быть легко помнить.
- Точный. Полезно, если имя отражает что-то о проекте.
- Положительный. Полезно, если противоположность имени непривлекательна. Например, Структурное программирование следует этому правилу, потому что никто не хочет быть неструктурированным.
- Умный. Умный является дополнительным, но это помогает сделать имя, незабываемое при достижении его. Умные возрасты плохо, все же.
Это не стоит ожидать к программе, пока у Вас нет прохладного имени. Чем больше опыта Вы имеете с проектом, тем легче назвать. JUnit не окрестили до спустя несколько месяцев после его дебюта.
Для получения дополнительной информации об именовании, я настоятельно рекомендую" Слова Который Работа: это не то, Что Вы Говорите, Это - то, Что Люди Слышат " Frank Luntz. Он - аморальный политический оператор, но он любит язык и передает ту любовь эффективно.
Одна последняя точка о "липких" проектах: обязательно скажите "миф о создании" часто, историю того, как проект начал. Каждый проект я видел это, имел долгосрочные последствия, имел часто повторенную историю о ее происхождении.
Я решил пойти с родовыми названиями для запуска, потому что я начал бы быстрое программирование и беспокойство об именах позже.
Этот Web 2.0 Генератор Имени интересен.
Если имя должно использоваться публично вообще - маркетинг, в сети, и т.д., просто уверен, что Вы выбираете имя что кто-то еще isn’t уже с помощью для чего-либо вообще подобного. По крайней мере, сделайте поиск Google. И прежде чем Вы тратите деньги на рекламу или что-либо как этот, тратите несколько маркеров, чтобы сделать поиск в одной из более специализированных баз данных наименования и товарного знака. По крайней мере, в США, будучи первым с именем дает Вам законные права и it’s более дешевый, чтобы сделать поиск, чем должными быть изменить Ваше имя позже.
, Конечно, прежде чем Вы зайдете слишком далеко, удостоверьтесь, что доменное имя доступно, также.
Для более сильных законных прав на имя, выберите что-то составленный that’s и не только общая ссылка к тому, что делает Ваш продукт. Кто-то как Microsoft может потратить океаны денег для получения правовой защиты чего-то как “Word” или “Windows” - Вы, вероятно, can’t.
При рассмотрении истории продуктов в целом существуют многочисленные примеры плохо выбранных имен, которые становятся частью языка (Клинекс, Вкусный-Freez, Wisker-Biskit), таким образом, я не думаю, что это имеет значение очень вообще с маркетинговой точки зрения. Вы действительно хотите что-то, что это легко ввести и записать по телефону, все же. Я работаю на компанию со странным именем с большим количеством Ss, которые походят на Фс, и это - кошмар.
Да, я думаю, что это имеет значение (находиться в том же положении сам). Я думаю имя или должен быть прохладным/незабываемым или очевидным/простым - не обязательно оба. Как показывает опыт, предположите поиск программы/библиотеки, которая делает то, что Ваш делает. Был бы имя Вы давать его, поощряют Вас или отталкивают Вас, и Вы помнили бы это? Это - действительно все, что имеет значение.
Прежде, чем обосноваться на названии Вашего приложения, можно хотеть проверить, чтобы видеть, доступно ли доменное имя.
Имеет значение, если Вы заботитесь о других людях, использующих Ваш код. Предпочтите незабываемые имена. Они могут быть незабываемы, потому что они являются описательными, или потому что они "прохладны", или по другой причине. Если Вы выкладываете свой код в Интернет, он должен включать описание, которое обнаружится в соответствующих поисках.
Google Friendly
- Что-то уникальное ( или хотя бы то, что вы можете получить на своей домашней странице в первых 10 результатах )
- Легко записать
Было бы твердо предложить, чтобы имя использовало, если мы не знаем, каков продукт.
кроме того, это много походит на вопрос о маркетинге. Я сказал бы, что что-то охлаждается и незабываемый, но является описательным также. iTunes приходит на ум.
Вы могли сделать обоих. Хорошим примером была бы Обувь для Ruby. это первоначально было названным (Или таким образом, они говорят), "WINDOWS MACLEAN'S MIDAS УДАЧИ", но затем он выбрал Обувь.
инструментарий/библиотека не имеет никакого отношения к обуви.
Я абсолютно думаю, что именование важно для Вашего проекта. Много проектов с открытым исходным кодом имеет эту проблему, которая заставляет их получить имена, которые выглядят прохладными на экране, но тверды высказаться. Это означает, что в минимуме Ваш веб-сайт должен иметь руководство по произношению, и что много людей будет смущено тем, как объявить Ваш проект. Имя с трудным произношением может представить некоторый внутренний конфликт, поскольку люди пытаются думать о Вашем проекте. Это прохладно, Cooyil, Coowheel, Обмотка или что? Что случилось с этими людьми, что они не могут назвать свой проект? Если они не могут назвать проект чем-то, что легко читаемо нормальными людьми в намеченной целевой аудитории, мы можем действительно доверять им для создания хорошего продукта?
Ожидают для выбора хорошего имени, пока у Вас нет чего-то хорошего для именования проекта. Не плохо себя чувствуйте об изменении на потрясающее имя, после того как Вы находите его, нет никакой потребности остаться связанной с любым именем, которое Вы использовали в разработке.
Я видел проект назвать быть большой проблемой. Я управлял приблизительно 20 программистами, продолжающими работать, возможно, 40 проектов, и это добралось, чтобы быть настоящей проблемой, когда у Вас есть проект, названный X, виртуальный каталог по имени Y, проект Visual Studio по имени Z, и т.д. Когда приложение пишет в журнал ошибок, какой проект - это? Кому это принадлежит? Мы создали базу данных проекта для получения всего этого, но будет лучше иметь конвенции, потому что база данных проекта не всегда завершена и актуальна.
я сопротивлялся этой идее, но может быть лучше иметь числа проекта . Кажется лучше иметь мнемонические названия проекта, но если у Вас есть много проектов, Вы сталкиваетесь с вопросами мнемосхемы для кого.
Не всегда учитывается вопрос о том, насколько легко вы можете найти свой проект в Google. Это может быть или не быть фактором, но вы можете быть заинтересованы в том, чтобы следить за тем, что сообщество / пресса говорят о вашем проекте.
Если он называется «Project X», «e», «Raptor» или « Фиолетовые окна », однозначный поиск практически невозможен. Помимо проблемы с доступностью доменного имени, выбор имени, которое не используется в каком-либо другом контексте, позволяет вам делать полезные вещи, например настраивать автоматические оповещения для комментариев в твитах / блогах по вашему проекту.
К сожалению, большинство этих имен трудно произносить / писать однозначно, так что это компромисс.