В случае, если каждый метод и переменная будут использоваться только , что является более правильной конвенцией?Compact Convention
Создание столько переменных, сколько необходимо:
var x = GmailApp.getInboxUnreadCount();
var email = GmailApp.getInboxThreads (0, x);
Сочинение код в одну строку:
var email = GmailApp.getInboxThreads (0, GmailApp.getInboxUnreadCount());
Последние, в разумных пределах. Но это в основном вопрос стиля в простых случаях.
Это означает, что если у вас есть вызов функции, который принимает 10 аргументов, и каждый из этих аргументов приходит из самого большого вызова функции, не делайте этого. Подумайте, кто после этого получит вашу базу кода.
«Является ли эта строка кода доступной для чтения с использованием менее локальных переменных? Или мне нужно разбить ее, чтобы лучше проиллюстрировать, что делает линия?» это вопрос, который вы должны задать себе. И в этом случае последнее вполне читаемо.
На самом деле, я бы сказал, первый пример менее читаемый из-за бесполезное локальное переменное именем x. Если вместо этого они были названы лучше, это может быть более жизнеспособным вариантом.
var unreadCount = GmailApp.getInboxUnreadCount();
var email = GmailApp.getInboxThreads (0, unreadCount);
Это лучше, но все же довольно ненужно в этом очень простом случае.
Это компромисс.
Первый пример легче читать и отлаживать. Он имеет 2 строки, где могут возникать ошибки. Для отладки это хорошо, потому что на каждую строку вызывается только одна функция.
Второй пример называется «одним лайнером» и может быть сложным для отладки, поскольку есть несколько вещей, которые могут вызвать ошибки в этой строке, но используют меньше памяти. Вероятно, незначительная сумма.
В этом примере
1. var unread = GmailApp.getInboxUnreadCount();
2. var email = GmailApp.getInboxThreads (0, unread);
Допустим, вы получите сообщение об ошибке в строке 2. Вы знаете, что getInboxThreads бросает ошибку.
1. var email = GmailApp.getInboxThreads (0, GmailApp.getInboxUnreadCount());
Теперь скажите, что вы получили сообщение об ошибке в строке 1. Вам нужно будет проверить оба метода.
Так что это действительно сводится к тому, что, по моему мнению, выглядит проще отлаживать. –
Другим важным моментом является пространство, в котором дополнительные символы занимают ваши файлы javascript. Поскольку эти файлы должны быть загружены клиентом, дополнительные символы могут иметь определенный вес при окончательном размере загрузки. Конечно, вы можете wfways obfuscate/minify/compress ваш файл, или это может быть не проблема, для вашей конкретной инфраструктуры ... Тем не менее, вы должны знать об этом. – lsoliveira
Технически это правда, но разница довольно минимальная, особенно когда gzipped. И в наши дни нет оправдания для обслуживания ungzipped js. И если вы являетесь средой, в которой находятся эти несколько байтов, тогда вам лучше использовать компрессор, который, вероятно, будет реорганизовать это для компиляции в любом случае. Таким образом, на самом деле нет особого оправдания, чтобы усложнить сохранение пропускной способности. Пусть автоматические инструменты сделают это для вас и напишут код самого высокого качества. –
Пропускная способность для меня не является проблемой, но это полезно знать в будущем.Спасибо за ваш ответ, это напоминает мне теорию о том, что «ваш код может быть написан только один раз, но его можно прочитать 1000 раз». –