Стартап проверить есть ли блоки над игроком

[alexandrage]

В данном случае речь идёт об дополнительном ненужном коде. Создавать отдельные переменные/ветвления не имеет смысла если можно коротко и ясно уместить в inline, а сверху написать небольшой коммент с разъяснениями и ссылками на JavaDocs. Хз что за глупые вопросы.

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

Внутри метода всегда локал вар, а имена остаются записаны так для галочки отдельно. Их даже можно стереть обфускатором. На время работы кода это влияет ровно никак.

 

[Reality_SC]

А зачем так много лишнего кода?

Читабельность.

Создавать отдельные переменные/ветвления не имеет смысла если можно коротко и ясно уместить в inline, а сверху написать небольшой коммент с разъяснениями и ссылками на JavaDocs.
P.S. В первом варианте виртуалка будет ставить локальное значение в стек, сверять его и прыгать по нужному ветвлению, и только после этого передавать результат. В моём же варианте она будет передавать результат проверки сразу в регистр.
Если компиляторы научились убирать ненужные ветвления и анализировать код до такого состояния чтобы понимать когда нужно убирать, а когда нет — тогда извиняюсь, ненужный срач вышел.

Внутри метода всегда локал вар, а имена остаются записаны так для галочки отдельно. Их даже можно стереть обфускатором. На время работы кода это влияет ровно никак.

Александр абсолютно прав. Компиляторы умеют избавляться от ненужных переменных примерно с годов, когда Java 1 ещё не вышла, т.к. это оптимизация, лежащая практически на самом видном месте, и относительно легко реализуемая.

Я бы в своём коде пошёл ещё дальше.
Для меня читабельность — это когда код, который ты читаешь, ведёт линейное повествование, в одном направлении.

public boolean isBlockUpTrue(Player player) {
    World world = player.getWorld();
    Location playerLocation = player.getLocation();

    int high = world.getHighestBlockAt(playerLocation)
            .getLocation()
            .getBlockY();

    return high > playerLocation.getBlockY();
}

Когда появляюются инлайны — код приходится читать не только вертикально, но и горизонтально.
Так же стоит помнить о том, что когда вы в своих этих инлайнах вызываете один и тот же метод дважды, может оказаться, что это "тяжёлый" метод, и вы сильно потеряете на этом.

 

[Nikolai_Faint]

Внутри метода всегда локал вар, а имена остаются записаны так для галочки отдельно. Их даже можно стереть обфускатором. На время работы кода это влияет ровно никак.

Это влияет лишь на то, как новичок будет писать в дальнейшем свой код, основываясь на таких примерах. Конечно можно заявить что оптимизатор на моменте компиляции все вырежет, но т.к это не всегда получается сделать (Т.к код имеет свойство ветвится, и опять же у компилятора лишь абстрактное понимание твоего кода. Если он видит что какая-то переменная используется только один раз в примере то будет оптимизировать это, но если он увидит что переменная покидает зону функции то конечно не будет оптимизировать это, более того, он оставит все как есть. Можешь скомпилировать такой пример, и распарсить листинг ассемблера жабы)

Компиляторы умеют избавляться от ненужных переменных примерно с годов, когда Java 1 ещё не вышла, т.к. это оптимизация, лежащая практически на самом видном месте, и относительно легко реализуемая.

Конечно, очевидная оптимизация локальных переменных это обыденное дело, но есть примеры куда сложнее. В этом и дело, учить новичка такому - плохая практика. Такие примеры объяснять нужно, а не писать.

Я бы в своём коде пошёл ещё дальше.
Для меня читабельность — это когда код, который ты читаешь, ведёт линейное повествование, в одном направлении.

В таком случае тебе нужно читать книжки. Самое смешное что в твоём примере толком и объяснения нету, если новичек будет это читать ему придётся гуглить каждую функцию.

Когда появляюются инлайны — код приходится читать не только вертикально, но и горизонтально.

Грамотная реализация - уместить объяснение работы кода в документацию.

Так же стоит помнить о том, что когда вы в своих этих инлайнах вызываете один и тот же метод дважды, может оказаться, что это "тяжёлый" метод, и вы сильно потеряете на этом.

А кто вызывает что-то дважды? Я лишь переместил вариант alexandrage в вид inline, о том что там внутри не знаю т.к уже практически 2 года ничего не разрабатываю под жавку. За это время кучу всего поменялось, возможно внутри что-то действительно вызывается два раза, но опять же не знаю. (Или ты про пример с getLocation, тогда более понятнее, но всё же за годы без практики я абсолютно забыл что и как работает в spigot'e)


p.s Опять же, моя позиция тут - "Пиши маленький код но с большой документацией", возможно это немного глуповато, но в моей практике я получаю с этого только пользу.
У всех разное мнение к тому какой должен быть код, и разное видение того что происходит внутри.
Спасибо за дискуссию.

 

[alexandrage]

Хрена ты тут пукан рвешь из за размера кода, может хватит уже? Не смеши людей.

 

[Reality_SC]

@Nikolai_Faint
Давай ещё раз посмотрим на твой код:

А зачем так много лишнего кода?

public boolean isBlockUp (Player player) {
return player.getWorld().getHighestBlockAt (player.getLocation()).getLocation().getBlockY() > player.getLocation().getBlockY();
}

Вот ты сделал инлайн метода player.getLocation(). Смотрим реализацию:

Итого твой инлайн вместо 1 создания нового объекта, где я вынес ссылку на созданную локацию в отдельную переменную, создаёт два.

То, чем ты предлагаешь нам заняться — преждевременная оптимизация.

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

Поддержу, из темы сваливаю.

 

[alexandrage]

И потом удивляются. куда же память так быстро уходит и почему gc вызывает лаги.