Если вы меняете код и плодите баги, то это не рефакторинг, а переделывание. Рефакторинг это по определению такие модификации кода, которые не отличимы снаружи модифицируемого кода.
Если выделить эту строчку в метод, то в ней уже будет нечего выделять, следовательно, логическая единица кода тут атомарна. Если она атомарна, то её не будет проще понять, есть в ней комментарий или нет. Есть исключения, например, с вариантом, когда используется несколько ++ в одном выражении. Но теперь ситуация такова, что код не атомарный и его можно переписать, заменяя на последовательное исполнение инструкций с явным использованием someValue += 1 в правильном порядке.
А смысл, если на метод есть юнит-тест? Это сразу и пример использования и тест и осязаемые ожидаемые результаты. Там и будет что-то типа следующего
[Test]
public void TestGetMaxOddDivizor()
{
var helper = new MathTricksHelper();
Assert.AreEqual(5, helper.GetMaxOddDivizor(10));
Assert.AreEqual(27, helper.GetMaxOddDivizor(27));
}
Разве мы от рождения знаем иностранные языки? Мы их учим.
В порядке мнения: если последним двум пунктам человек не может научиться, то ему нечего делать в программировании. В конце концов, код программ на языках высокого уровня это практически текст. И программист в некотором смысле писатель/переводчик.
Теперь понял. И согласен с вами, что коммент, пожалуй, более уместен. Вот только это не типичная, а скорее исключительная ситуация, не находите? Если у вас так много деталей, приходящих из ТЗ, то можно оформить их в виде юнит-тестов, которые будут являться документацией к коду.
На все три пункта я говорю: «надо учиться». Первый пункт простителен, потому что выучить язык, пусть и не для разговора, очень непросто. А последние два надо исправлять. Мы же не на ассемблере преимущественно кодим.
Предлагаю примерно такой код (псевдокод, близкий к c#):
var lowMemory = Environment.AvailableMemoryInBytes < ERQUIRED_MEMORY_IN_BYTES;
var calculationPolicy = = new CalculationPolicy();
var calculator = new UniversalCalculator();
CalculationResult calculationResult = null;
if (lowMemory && calculationPolicy.HandleLowMemoryCaseSeparately)
calculationResult = calculator.CalculateApproximately(someArguments);
else
calculationResult = calculator.CalculatePrecisely(someArguments);
Для тех, кто не любит такие if'ы и подобные switch'и, можно вообще всё это дело упаковать в саму политику, чтобы она возвращала делегат:
var lowMemory = Environment.AvailableMemoryInBytes < ERQUIRED_MEMORY_IN_BYTES;
var calculationPolicy = new CalculationPolicy();
// Политика предоставит тот вычисляющий объект (Calculator), который требуется.
Func<?, CalculationResult> calculator = calculationPolicy.GetCalculator(lowMemory);
CalculationResult calculationResult = calculator.Calculate(someArguments);
Переделайте генератор, в чём проблема? Или (это полушутка) не читайте генерируемый код :)
Подавляющему большинству переменных можно дать хорошее, осмысленное, информативное имя (иногда, правда, несколько длинное). Потому что люди мыслят словами. Когда мои коллеги говорят «не знаю, как назвать класс/метод/переменную», обычно это означает одно из следующего:
— коллега оставил попытки найти имя, т.е. быстро сдался;
— коллега нуждается в совете/совсем неопытен;
— кому-то банально лень.
Пока ехал в метро, ответить не мог, а мысль пришла ровно такая же. «Пойму ли по прошествию времени?» А вообще, всего, что касается объяснений, отец учил делать так, чтобы «и дураку было ясно».
Ещё одна интересная мысль (не моя, естественно), которая актуальна для программистов, работающих с высокоуровневыми языками: Как правило любые комментарии можно (и нужно) переделать в код. Очевидно, код будет понятен в такой же степени, в которой ясны исходные комментарии. Это, кстати, есть у того же Макконнелла, который рассказывает про написание методов сверху-вниз: псевдокод — комментарий — код.
И ещё. Комментарии не должны учитывать «целевую аудиторию»! Потому что мы про эту аудиторию ничего не можем сказать. Junior'а будет раздражать отсутствие комментариев, а senior'а — наличие. Так что критерий для писать/не писать коммент должен быть иной.
Шансов-то больше, да. Но практика показывает, что это не мешает им тухнуть. Как только дело доходит до решений, в которых есть вариант, опирающийся на дисциплину, я стараюсь трезво-трезво смотреть на ситуацию.
[irony] Если везде расставлять комментарии для junior'ов, то никакого жесткого диска для исходников не хватит. [/irony] А если серьезно, то комментарии должны описывать непонятные места, решения и хаки, которых никак не избежать. В остальных случаях нет никакого смысла писать одно и то же дважды.
Комментарии для документации, как было сказано выше, — отдельный разговор.
Так вы сами ответили на свой вопрос. Проблема с именованием, а вовсе не с тем, что нужно что-то прокомментировать. Перепишите так, чтобы читалось и всё. В первую очередь лично меня, мало использующего Java, смущает длина этой колбасы: com.bzpn.vpp.system.cup.FGCFTemplateImplication.removeEntity(broken); Оно должно быть сокращено до просто читаемого FGCFTemplateImplication.removeEntity(broken).
В порядке мнения: если последним двум пунктам человек не может научиться, то ему нечего делать в программировании. В конце концов, код программ на языках высокого уровня это практически текст. И программист в некотором смысле писатель/переводчик.
Предлагаю примерно такой код (псевдокод, близкий к c#):
Для тех, кто не любит такие if'ы и подобные switch'и, можно вообще всё это дело упаковать в саму политику, чтобы она возвращала делегат:
Подавляющему большинству переменных можно дать хорошее, осмысленное, информативное имя (иногда, правда, несколько длинное). Потому что люди мыслят словами. Когда мои коллеги говорят «не знаю, как назвать класс/метод/переменную», обычно это означает одно из следующего:
— коллега оставил попытки найти имя, т.е. быстро сдался;
— коллега нуждается в совете/совсем неопытен;
— кому-то банально лень.
Ещё одна интересная мысль (не моя, естественно), которая актуальна для программистов, работающих с высокоуровневыми языками: Как правило любые комментарии можно (и нужно) переделать в код. Очевидно, код будет понятен в такой же степени, в которой ясны исходные комментарии. Это, кстати, есть у того же Макконнелла, который рассказывает про написание методов сверху-вниз: псевдокод — комментарий — код.
Комментарии для документации, как было сказано выше, — отдельный разговор.