Учитывая этот метод, представляет ли это какой-то вопиющий стилистический или семантический faux pas:
private double translateSlider(int sliderVal) {
switch (sliderVal) {
case 0:
return 1.0;
case 1:
return .9;
case 2:
return .8;
case 3:
return .7;
case 4:
return .6;
default:
return 1.0;
}
}
Это явно не соответствует учебникам Java здесь.
Однако, это ясно, кратким и до сих пор дало именно то, что мне нужно. Есть ли убедительная, прагматичная причина для создания локальной переменной, присваивать ей значение в каждом случае, добавлять разрыв в каждый случай и возвращать значение в конце метода?
Назначение значения локальной переменной и последующее возвращение в конце считается хорошей практикой. Методы, содержащие несколько выходов, сложнее отлаживать, и их трудно прочитать.
Тем не менее, это единственный плюс, оставленный этой парадигме. Это было начато, когда были только низкоуровневые процедурные языки. И в то время это имело гораздо больше смысла.
Пока мы говорим по этой теме, вы должны проверить это. Его интересное чтение.
С точки зрения человеческого интеллекта ваш код в порядке. Из анализа инструментов статического анализа кода есть несколько возвратов, что затрудняет отладку. например, вы не можете установить одну и только точку останова сразу перед возвратом.
Кроме того, вы не будете жестко кодировать 4 шага слайдера в профессиональном приложении. Либо вычисляйте значения с помощью max-min и т.д., Либо найдите их в массиве:
public static final double[] SLIDER_VALS = {1.0, 0.9, 0.8, 0.7, 0.6};
public static final double SLIDER_DEFAULT = 1.0;
private double translateSlider(int sliderval) {
double ret = SLIDER_DEFAULT;
if(sliderval >= 0 && sliderval < SLIDER_VALS.length) {
ret = SLIDER_VALS[sliderval];
}
return ret;
}
Это отлично, если у вас нет кода, следующего за вашим блоком переключения в методе.
Но в качестве общей хорошей практики программирования вы должны избегать слишком большого числа операторов return, поскольку это уменьшает читаемость вашего кода.
Лучшим случаем для человеческой логики для генерируемого компьютером байт-кода будет использование кода, как показано ниже:
private double translateSlider(int sliderVal) {
float retval = 1.0;
switch (sliderVal) {
case 1: retval = 0.9;
case 2: retval = 0.8;
case 3: retval = 0.7;
case 4: retval = 0.6;
case 0:
default: break;
}
return retval;
}
Таким образом, elminating multible выходит из метода и использует язык логически. (т.е. в то время как sliderVal представляет собой интергеровский диапазон от 1-го поплавкового значения else else, если sliderVal равен 0 и всем другим значениям, retval остается равным значению float 1.0)
Однако, что-то вроде этого с каждым целым значением sliderVal, являющимся (n-(n/10)), действительно может просто сделать лямбда и получить более быстрые результаты:
private double translateSlider = (int sliderVal) -> (1.0-(sliderVal/10));
Изменить: Модуль 4 может быть для того, чтобы сохранить логику (т.е. (n-(n/10))%4))
Нет, у вас все в порядке. Вы также можете сделать это как формулу (sliderVal < 5 ? (1.0 - 0.1 * sliderVal) : 1.0) или использовать Map<Integer,Double>, но то, что у вас есть, хорошо.
Я предлагаю вам не использовать литералы.
Кроме того, сам стиль выглядит хорошо.
Если у вас будет метод, который просто запускает коммутатор, а затем возвращает некоторое значение, то уверен, что этот способ работает. Но если вам нужен переключатель с другим материалом в методе, то вы не можете использовать return или остальная часть кода внутри метода не будет выполняться. Обратите внимание в учебнике, как он печатает после кода? Вы не сможете этого сделать.
Почему не просто
private double translateSlider(int sliderval) {
if(sliderval > 4 || sliderval < 0)
return 1.0d;
return (1.0d - ((double)sliderval/10.0d));
}
Или похоже?
Да, это хорошо. Учебники не всегда конкретизируются и аккураты. Мало того, что создание локальных переменных - это потеря пространства и неэффективность
Я думаю, что то, что вы написали, прекрасно. Я также не вижу проблемы с читабельностью, имея несколько операторов return. Я всегда предпочел бы вернуться с точки в коде, когда я знаю, чтобы вернуться, и это позволит избежать запуска логики ниже возврата. Тем не менее, может быть аргумент наличия единственной точки возврата для отладки, а также ведения журнала, если таковой имеется. Но в вашем коде нет необходимости отлаживать и регистрировать, если мы его используем. это очень просто и понятно, как вы написали.