С Git/Mercurial и прочими, всё становится на свои места.
SVN… это тоже плохая черта, причём говорящяя много обо всех, кто его использует в проекте. Почему? Ну, использовать инструменты двадцатилетней свежести, когда есть толковые современные замены — это всё же показатель низкой квалификации.
… однако я пользуюсь гитхабом(точнее аналогом bitbucket), и что? это разве означает что что у меня квалификация выше?
GitHub это de facto стандарт для open source проектов. Не пытаться разобраться с ним, чтобы сделать один простой push вместо того, чтобы делиться проектом через файлообменник или распределённую файловую систему, таки говорит о квалификации разработчика много.
зато ваш отзыв о том кто не пользуется тем инструментом которым пользуетесь вы, многое говорит о вас как о человеке, и о вашем отношении к людям.
Да, и я не против. Привык быть строгим ко всем и к себе.
P.S. А ещё я не против того, чтобы меня считали мудаком, ага.
У вас неверная информация в некоторых моментах. On call существует. И это не плохо, а хорошо. Бережливость — и да и нет. Ноуты средние, но они не для разработки в Амазоне. Вторые мониторы есть (может, не у всех, конечно). Что за бред, что их нет? Lump sum (relocation) переводят дня за два, после того как предоставите данные по счёту. Green card точно не знаю. Вроде, действительно, не сразу.
English Grammar in Use, Murphy. А потом Advanced Grammar in Use, Hewings. И то и другое — руководства и практика для самостоятельного изучения. Лучше ещё ничего не придумали, я считаю.
Практика, практика и ещё раз практика. Грамматику можно хорошо освоить дома самостоятельно. Сравниваю сейчас с курсами при МИД и месячными курсами в Caplan School (Dublin) и понимаю, что именно дома грамматику и надо учить, не бросать денег на ветер.
С phrasal verbs и вообще словарём, особенно активным, всё намного сложнее, но тоже посильно. Тут и книжки специальные и художка и фильмы — всё хорошо.
Теперь понял, о чём вы. Только вы, кажется, не услышали меня. Если я улучшаю код путём рефакторинга и вношу ошибку, то это не рефакторинг. Потому что эквивалентные преобразования кода не могут внести ошибку. Следовательно, преобразования не эквивалентные, а значит, это по определению не рефакторинг. Я хотел только это сказать.
Что касается дилеммы «читабельность против производительности», я для себя решил, что всегда «по умолчанию» выбираю читабельность. До того как профилировщик покажет мне, что всё плохо, я не буду оптимизировать скорость. Понятный код меньше подвержен багам. В большинстве случаев пользователи предпочтут чуть более медленную, но правильно работающую программу, более быстрому аналогу, имеющему ошибки. Последнее утверждение, правда, очень сильно зависит от софта. Например, разработчики кодеков, видеопроигрывателей и т. п. могут пожертвовать точностью и даже позволить себе некоторые баги (артефакты на экране, например), лишь бы программа работала быстро.
В данном случае комментарии попросту эквивалентны коду и им нельзя не быть хорошими. Иначе поломается семантика и программа не будет работать так, как задумано.
В C# code contracts там где могут проверяются на компиляции (статический анализ). Помимо этого они также проверяются при исполнении. По поводу DEBUG/RELEASE с ходу не отвечу, но процитирую вот это:
Most methods in the contract class are conditionally compiled; that is, the compiler emits calls to these methods only when you define a special symbol, CONTRACTS FULL, by using the #define directive. CONTRACTS FULL lets you write contracts in your code without using #ifdef directives; you can produce different builds, some with contracts, and some without.
Скорее он говорит, что комментарии должны [автомагически] разворачиваться в исполняемый код, а программирование — сводиться к чему-то схожему с написанием рассказов.
Сами формулы могут прекрасно жить в документации/ТЗ. На них можно и иногда даже нужно ссылаться из кода. Но тут есть проблема синхронизации нумерации разделов/глав/пунктов в документации и комментариях.
Да ничего подобного. Всё, что вы сделали — только вынесли метод. А тут ещё как минимум надо вынести константы, придав им заодно информативные имена. Приведённый код всё ещё недостаточно хорош, чтобы легко читаться без комментариев.
Помимо этого, если этот метод должен работать в среде с какими-то ограничениями, то настаёт время контрактов (Code contracts). Я не очень знаю что делает ваш код, так что покажу лишь направление модификации кода, чтобы он не требовал комментариев.
В C# вы можете написать как-то так, например:
private int ExtractXBits(int mask)
{
Contract.Requires(mask >= 0, "mask >= 0");
Contract.Requires(mask <= 10, "mask <= 10.");
// Это значение я заименовать не смог правильно, потому что не понял его.
const int CONST_A = 0x09249249;
const int INT_WITH_15_SET_LOWER_BITS = 0x7ff;
var intAfterMaskApplied = (mask & CONST_A); // Тут имя переменной надо подобрать удачнее.
var index = intAfterMaskApplied % INT_WITH_15_SET_LOWER_BITS; // index тоже плохенькое имя.
return RestoreXBits[index];
}
Вот когда код будет «вылизан» так, что никто в команде уже не может сделать его лучше, а «понимабельность» всё ещё не на высоте, то настаёт время комментариев.
Код можно писать так, что не возникнет нужды в документации, потому что он будет практически идентичен ей. Тогда от комментарии будут не нужны, а лишь опасны. Если же держать и код и комменты, то получаем, что код плох, а комменты всё так же опасны.
Мы вообще не говорили о производительности. Речь была именно что о багах.
Позволю себе процитировать пару определений, чтобы было ясно и ещё подчеркну кое-что в них. По определению рефакторинг исключает внесения багов. Если они внесены, это всё же не рефакторинг. Правильный рефакторинг ведётся, например, инструментами (по типу Resharper, который иногда, правда, давал осечки в моей практике) в связке с юнит-тестами, которые «проверяют», что баги не вносятся.
С вики:
Рефа́кторинг (англ. refactoring) или реорганизация кода — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований.
С другого сайта:
Рефакторинг — это процесс улучшения написанного ранее кода путем такого изменения его внутренней структуры, которое не влияет на внешнее поведение.
А что до LINQ, врать не буду. У меня ни малейшего представления, как его рефакторить. С ходу могу понять, что кое-где может быть уместно вынесение переменной. В остальном я вижу для LINQ не рефакторинг, а именно переделывание/переписывание/модификацию. Называйте как угодно.
SVN… это тоже плохая черта, причём говорящяя много обо всех, кто его использует в проекте. Почему? Ну, использовать инструменты двадцатилетней свежести, когда есть толковые современные замены — это всё же показатель низкой квалификации.
GitHub это de facto стандарт для open source проектов. Не пытаться разобраться с ним, чтобы сделать один простой push вместо того, чтобы делиться проектом через файлообменник или распределённую файловую систему, таки говорит о квалификации разработчика много.
Да, и я не против. Привык быть строгим ко всем и к себе.
P.S. А ещё я не против того, чтобы меня считали мудаком, ага.
Это много говорит о квалификации.
> Впрочем, есть люди, которым всегда все не нравится. Поэтому оставлю как есть.
Впрочем, есть люди, которым всегда тяжело проходить pull request/code review и воспринимать критику кода.
Ох… Прям совсем-совсем?
Практика, практика и ещё раз практика. Грамматику можно хорошо освоить дома самостоятельно. Сравниваю сейчас с курсами при МИД и месячными курсами в Caplan School (Dublin) и понимаю, что именно дома грамматику и надо учить, не бросать денег на ветер.
С phrasal verbs и вообще словарём, особенно активным, всё намного сложнее, но тоже посильно. Тут и книжки специальные и художка и фильмы — всё хорошо.
Что касается дилеммы «читабельность против производительности», я для себя решил, что всегда «по умолчанию» выбираю читабельность. До того как профилировщик покажет мне, что всё плохо, я не буду оптимизировать скорость. Понятный код меньше подвержен багам. В большинстве случаев пользователи предпочтут чуть более медленную, но правильно работающую программу, более быстрому аналогу, имеющему ошибки. Последнее утверждение, правда, очень сильно зависит от софта. Например, разработчики кодеков, видеопроигрывателей и т. п. могут пожертвовать точностью и даже позволить себе некоторые баги (артефакты на экране, например), лишь бы программа работала быстро.
Уменьшает читабельность? Я не согласен.
Помимо этого, если этот метод должен работать в среде с какими-то ограничениями, то настаёт время контрактов (Code contracts). Я не очень знаю что делает ваш код, так что покажу лишь направление модификации кода, чтобы он не требовал комментариев.
В C# вы можете написать как-то так, например:
Вот когда код будет «вылизан» так, что никто в команде уже не может сделать его лучше, а «понимабельность» всё ещё не на высоте, то настаёт время комментариев.
Позволю себе процитировать пару определений, чтобы было ясно и ещё подчеркну кое-что в них. По определению рефакторинг исключает внесения багов. Если они внесены, это всё же не рефакторинг. Правильный рефакторинг ведётся, например, инструментами (по типу Resharper, который иногда, правда, давал осечки в моей практике) в связке с юнит-тестами, которые «проверяют», что баги не вносятся.
С вики:
С другого сайта:
А что до LINQ, врать не буду. У меня ни малейшего представления, как его рефакторить. С ходу могу понять, что кое-где может быть уместно вынесение переменной. В остальном я вижу для LINQ не рефакторинг, а именно переделывание/переписывание/модификацию. Называйте как угодно.