BigVOVA
30 уровень

Вырабатываем правильные привычки

Пост из группы Архив info.javarush.ru
3786 участников
Привет Всем! Мне уже 40ет. Хочу сменить карьеру. Точнее я свою трудовую деятельность начинал с программирования. В старые времена работал с базами ForPro, dBase. Давалось все без проблем. Потом вскочил в мелкий бизнес. Больших успехов не достиг. Точнее так... Задолбалось выползать из кризисов, чтоб через несколько лет тебя новый накрыл. Вот и решил вернуться в базы но со сторону ООП. Курс очень понравился. Пока, 8-ой уровень, задачки идут как семечки. Но, дают о себе знать старые привычки. Допустим, я стараюсь по минимуму плодить переменные/ссылки если они участвуют в процессе один раз. Но анализирую решения задач от других участников, вижу, что люди фигачат лишние переменные на право и на лево. Хочется "поставить руку" (стиль) еще в процессе обучения. Вот конкретный пример: Мой код: public static long getTimeMsOfInsert(List list) { //Напишите тут ваш код long startTime = new Date().getTime(); insert10000(list); //Напишите тут ваш код return new Date().getTime() - startTime; } В чужих решениях встречаю приблизительно следующее: public static long getTimeMsOfInsert(List list) { //Напишите тут ваш код long startTime = new Date().getTime(); insert10000(list); //Напишите тут ваш код long finishTime = new Date().getTime(); // мне кажется это лишнее return finishTime - startTime; } Как более грамотно учитывая все моменты, а именно производительность, читаемость и пр.
Комментарии (11)
  • популярные
  • новые
  • старые
Для того, что бы оставить комментарий вы должны авторизоваться
BigVOVA30 уровень
29 марта 2015, 18:02
Очередной вопрос…

Менять переменные лучше через промежуточную или через сумму?

tmp = i;
i = j;
j = tmp;


VS

i = i + j;
j = i - j;
i = i - j;
Kishuomi22 уровень, Новосибирск
29 марта 2015, 19:00
Более легкое восприятие VS экономия памяти.
Какая задача приоритетнее такой код и выбираем.
BigVOVA30 уровень
29 марта 2015, 19:47
экономия памяти через сумму? Правильно?
Kishuomi22 уровень, Новосибирск
29 марта 2015, 20:05
Да. tmp где то будет размещена. Я пологаю выбор релизации зависи от приоритета цели в проекте.
BigVOVA30 уровень
29 марта 2015, 20:44
Ok. А по скорости какая кострукция лучще?
Airon34 уровень, Киев
29 марта 2015, 20:46
Конечно же простое присвоение. Ведь во 2 варианте не только нужно выполнить такое же кол-во присвоений, но еще и 3 арифметические операции.
Airon34 уровень, Киев
29 марта 2015, 20:54
Какая экономия может быть, внутри все равно промежуточный результат арифм операции как то сохраняется.
и что если 1 вариант переписать как:
{
int tmp = i;
i = j;
j = tmp;
}
тогда за скобками так же перестанет существовать tmp, как и во втором случае.
BigVOVA30 уровень
11 марта 2015, 21:55
Спасибо ребят! Вы, в принципе подтвердили мои догадки как и то, что в этой индустрии за почти 20 лет ничего не поменялось)))
EvIv30 уровень
11 марта 2015, 19:32
В последнее время идет тренд в сторону лучшей читаемости кода, немного в ущерб производительности. В больших проектах важно создавать поддерживаемые решения, чтобы можно было либо самому через какое-то время вернуться к этому коду, либо кому-то из коллег. При этом время разработчика чаще гораздо дороже машинного времени, а ресурсы на многих мелочах уже давно можно не считать в большинстве задач (исключая немногие узкие места, которые оптимизируют отдельно и после соответствующего исследования — профилирования). Поэтому общая рекомендация будет: если введение временных, одноразовых переменных улучшит читаемость кода, вводить их. Могу порекомендовать к прочтению книгу Стивена Макеоннела «Совершенный код» — там много полезных рекомендаций по написанию хорошего кода.
EvIv30 уровень
11 марта 2015, 19:49
МакКоннела, конечно же
rory-breaker9 уровень
11 марта 2015, 19:05
Нет никакого смысла в создании переменной finishTime в данном примере,
return new Date().getTime() - startTime;

вполне читаемо, не думаю что создание одной переменной сильно повлияет на производительность(мб компилятор оптимизирует и не будет ее создавать).
На счет стиля кода читайте java code conventions.