hVosttАлексей ККупить решарпера и отключить его возможности, чтобы не мешал - заманчиво!

Уверен, что ты и половины возможностей только одной Visual Studio не знаешь.Меньше знаешь - крепче спишь. Всё знать невозможно. Ничего лишнего знать не хочу, мне это мешает.

Где-то в степиАлексей К,
авторКупить решарпера и отключить его возможности, чтобы не мешал - заманчиво!
ну нун ну ну, тока нинадо мне приписывать чего не говорил, настроить под требования и отключить - вроде как бы разные
тагедацииНу если требования требуют отключения.

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

Ты какую тупую чушь несёшь, честное слово. Не позорься.Где чушь? Что много проектов? Что они разные? Что их переписывать не надо? Что новые средства разработки? Что опыт растёт?

hVosttАлексей КМне кажется, что все имеют право высказаться, как сторонники, так и противники. :-)

У сторонников крепкая аргументация на тему почему решарпер нужен.У противников аргументация не менее крепкая: "Возможностей VS достаточно".

И родной rename меня устраивает, и скобочки двигать мне ни разу не хотелось. Жертвы маркетинга, одним словом.

hVosttАлексей КГде чушь? Что много проектов? Что они разные? Что их переписывать не надо? Что новые средства разработки? Что опыт растёт?

Чушь в том, что ты отрицаешь важность единого стиля.Этого я не отрицаю. Просто жизнь вносит свои коррективы. Да и фанатичная "единая стилизация кода" несёт больше вреда чем пользы. Как всегда, нужно выбирать компромисс между желаемым и действительным.

Недавно наблюдал следующие требования:
1. Должны быть удалены все неиспользуемые using namespace-ов.
2. namespace в файлах должны соответствовать структуре каталогов, в которой располагаются файлы.
3. Ну и ещё полкило бреда...

И это на фоне ошибок и недостаточного описания предметной области. Мне кажется, что есть масса других вопросов, на которых следует сконцентрироваться.

hVosttПри чём тут несколько проектов? В каждом проекте теперь будет свой стиль кодирования? Да, стандарты совершенствуются, переписывать никто не будет. И чо? Единый стиль теперь не нужен? Ты либо чушь несёшь, либо говори конкретней что хочешь сказать. Какой тезис ты донести пытаешься? Типа буду кодить как хочу, а на остальных мне насерить?Мне показалось, что я достаточно ясно описал ситуацию.
hVosttТак ты работал когда-нибудь в команде или нет?Так сложилось, что я всегда руководил командой. Все попытки перенять чей-то опыт оканчивались неудачей. В моём окружении, к сожалению, никогда не было достойных учителей.

Где-то в степиАлексей К,
авторМеньше знаешь - крепче спишь. Всё знать невозможно. Ничего лишнего знать не хочу, мне это мешает.
опять пичалька ((
ученые доказали, что основными печенюшками для мозга является получение новой информации ( говоря проще, если не получать
печенюшки, можно быстро состариться и помереть) , ну щас начнутся истерики ( переизбыток информации - ведет к стрессам)
но мы говорим о информации в контексте профессиональных навыков, в этом то контексте программист должен знать или по крайней мере стремится получить знания, а не зарывать голову в песок.
О толерантности: Конечно человек ( и тем более человек разумный) должен иметь свое мнение о обсуждаемых аспектах
и даже наверное приветствуется аргументированное доказательство своего мнения, но огульное безапелляционное нигилирование
к оппоненту сводит диспут на уровень дамбаса головного мозга, не правда ли?В наше время свободного интернета очень много дезинформации и откровенной тупости. Тратить время на изучение тупости смысла не вижу. Лучше доверять своему опыту, оно как-то надёжнее. Сегодня мне решарпер не нужен, и никто не в силах заставить меня им пользоваться. Завтра ситуация может измениться, но это будет завтра. Сегодня у меня есть масса более актуальных задач.

Где-то в степиученые доказали, что основными печенюшками для мозга является получение новой информации ( говоря проще, если не получать печенюшки, можно быстро состариться и помереть) , ну щас начнутся истерики ( переизбыток информации - ведет к стрессам)Ну повёлся я как-то на "стильно, модно, молодёжно" . И что в итоге? Кто компенсирует мне бездарно прожитую неделю?

hVostt1. Да, должны быть удалены, так как лишние неиспользуемые неймспейсы мешают чтению кода.Мне не мешают, я вообще на них редко обращаю внимания. И кто из нас прав? Зачем тратить время на такие мелочи?
hVosttИмеются исключения из этого правила, например, System и System.Linq.В нормальном правиле исключений быть не должно.
hVostt2. Да, неймсейсы в подавляющем случае должны соответствовать структуре каталогов. Однако есть исключения из этого провала, и как правило они обоснованы (App_Start, каталоги, нужные исключительно для организации файлов, а не структуры кода).Если в большинстве случаев namespacы делать, как ты говоришь - обилие using-ов в прикладном коде превысит все границы разумного. Рефакторинг кода будет похож на АД! Вероятно - да, при таком подходе решарперы нужны.

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

hVosttАлексей КМне показалось, что я достаточно ясно описал ситуацию.

Нет. Я так и не понял, осознаешь ли ты важность единого стиля кода, или ты против каких-то стилей, так у тебя миллион разных проектов, ситуаций и команд, и везде всё как бог на душу положит?Везде есть свои принципы и правила, но они разные.

hVosttАлексей КНу повёлся я как-то на "стильно, модно, молодёжно" . И что в итоге? Кто компенсирует мне бездарно прожитую неделю?

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

hVosttАлексей КМне не мешают, я вообще на них редко обращаю внимания. И кто из нас прав? Зачем тратить время на такие мелочи?

1) Затем, что дьявол скрывается в мелочах.
2) А о тебе речи не идёт. Все мои рассуждения в контексте командной разработки и с учётом, что кто-другой, возможно, будет сопровождать и дорабатывать твоё творение. Не буду говорить что я думаю и как отношусь к тем, кто клал толстый хер на всех.Единый стиль для всех программистов планеты - утопия. А нерешаемые задачи могут решать только странные люди. :-)

hVosttАлексей КВ нормальном правиле исключений быть не должно.

Только что придумал?Всегда так было.

hVosttАлексей КЕсли в большинстве случаев namespacы делать, как ты говоришь - обилие using-ов в прикладном коде превысит все границы разумного. Рефакторинг кода будет похож на АД! Вероятно - да, при таком подходе решарперы нужны.

Что это за границы? 5, 10, 15 юзингов? Давай конкретней. С решарпером проблемы с неймспейсами полностью снимаются, так как он за ними следит, так что ты вообще про них забываешь.

Вводишь наименование класса, которого нет в юзингах, решарпер автоматом его добавляет. Юзинг стал не нужен? Решарпер удаляет. Никакого ада. А вот без решарпера, действительно, будет АД.Ну а я о чём говорю? Не нужно создавать АД, не потребуются усилия для его преодоления.

hVosttАлексей КНикто никому ничего не должен. Каждый должен делать как ему удобнее. Есть техническое задание, оно должно быть выполнено в установленные сроки. Ничего больше нет! Но это другая крайность. Повторюсь, нужно искать компромисс.

Зачем ты собираешься искать компромис, если общие стандарты уже давно устоялись? Решарпер эти стандарты использует для подстветки кода, так как подавляющее большинство с ним согласно. Я считаю, что нонконформизму и юношескому максимализму не место в кодинге. Ты же ведёшь себя как маленький ребёнок: «не хочу, как все!!! я личность!!!!» Ой да ладно. Различия в форматировании функциональных элементов языка и LINQ-запросов в наше время особенно стандартизированы. Расскажи эти сказки МСУ, может он поверит. Где кстати он?
hVosttАлексей КВезде есть свои принципы и правила, но они разные.

Бла-бла-бла — примерно тоже самое, что ты сказал, только короче. Ни о чём.Например, у меня в разных проектах исторически сложилось три принципа именования классов-сервисов:
1. MgrPersonal.
2. SvcPersonal.
3. PersonalService.

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