Что лучший способ состоит в том, чтобы организовать код? [закрытый]
Можно проверить только расширение файла, но пользователь может легко переименовать virus.exe на virus.jpg и «передать» проверку.
Для чего это стоит, вот код для проверки файла расширение и прервать, если не соответствует одному из допустимых расширений: (выберите недопустимый файл и попытайтесь отправить, чтобы увидеть предупреждение в действии)
var _validFileExtensions = [".jpg", ".jpeg", ".bmp", ".gif", ".png"];
function Validate(oForm) {
var arrInputs = oForm.getElementsByTagName("input");
for (var i = 0; i < arrInputs.length; i++) {
var oInput = arrInputs[i];
if (oInput.type == "file") {
var sFileName = oInput.value;
if (sFileName.length > 0) {
var blnValid = false;
for (var j = 0; j < _validFileExtensions.length; j++) {
var sCurExtension = _validFileExtensions[j];
if (sFileName.substr(sFileName.length - sCurExtension.length, sCurExtension.length).toLowerCase() == sCurExtension.toLowerCase()) {
blnValid = true;
break;
}
}
if (!blnValid) {
alert("Sorry, " + sFileName + " is invalid, allowed extensions are: " + _validFileExtensions.join(", "));
return false;
}
}
}
}
return true;
}<form onsubmit="return Validate(this);">
File: <input type="file" name="my file" /><br />
<input type="submit" value="Submit" />
</form> Обратите внимание, что код позволит пользователю отправлять без выбора файла ... если требуется, удалите строку if (sFileName.length > 0) { и свяжите ее с закрывающей скобкой. Код будет проверять любой входной файл в форме независимо от его имени.
Это можно сделать с помощью jQuery в меньшем количестве строк, но мне достаточно удобно с «сырым» JavaScript, и конечным результатом является
Если у вас больше файлов или вы хотите активировать проверку при изменении файла, а не только при отправке формы, используйте такой код:
var _validFileExtensions = [".jpg", ".jpeg", ".bmp", ".gif", ".png"];
function ValidateSingleInput(oInput) {
if (oInput.type == "file") {
var sFileName = oInput.value;
if (sFileName.length > 0) {
var blnValid = false;
for (var j = 0; j < _validFileExtensions.length; j++) {
var sCurExtension = _validFileExtensions[j];
if (sFileName.substr(sFileName.length - sCurExtension.length, sCurExtension.length).toLowerCase() == sCurExtension.toLowerCase()) {
blnValid = true;
break;
}
}
if (!blnValid) {
alert("Sorry, " + sFileName + " is invalid, allowed extensions are: " + _validFileExtensions.join(", "));
oInput.value = "";
return false;
}
}
}
return true;
}File 1: <input type="file" name="file1" onchange="ValidateSingleInput(this);" /><br />
File 2: <input type="file" name="file2" onchange="ValidateSingleInput(this);" /><br />
File 3: <input type="file" name="file3" onchange="ValidateSingleInput(this);" /><br />Это отобразит предупреждение и сбросит ввод в случае недопустимого расширения файла.
11 ответов
я обычно заказываю следующим
- конструкторы
- деструкторы
- методы считывания
- методы set
- любые 'волшебные' методы
- методы для изменения сохраненного состояния получателя (сохраняют () и т.д.),
- поведения
- общедоступные вспомогательные методы
- частные/защищенные вспомогательные методы
- что-либо еще (хотя, если обычно существует что-либо еще знак, что некоторый рефакторинг необходим),
Я склонен использовать следующий шаблон:
- общедоступные статические последние переменные
- статические функции, статические блоки
- переменные
- конструкторы
- функции, которые делают что-то связанное с логикой
- методы считывания и методы set (uninteresing главным образом, таким образом, нет никакой потребности считать их),
Я, не имеют никакого шаблона включения локальных классов, и главным образом я поместил их сверху первого метода, который использует их.
Мне не нравится разделять методы в зависимости от уровня доступа. Если некоторый открытый метод будет использовать некоторый закрытый метод, то они будут друг близко к другу.
Я склоняюсь к групповым методам, которые касаются друг друга. Использование хорошего IDE удаляет большую часть этого беспокойства. Расположение в алфавитном порядке методов походит на трату усилия мне.
Я группирую их на основе того, что, там делая, и затем в порядке я записал им (в алфавитном порядке будет probs быть лучше хотя),
например, в texture.cpp я имею:
//====(DE)CONSTRUCTOR====
...
//====LOAD FUNCTIONS====
...
//====SAVE FUNCTIONS====
...
//====RESOURCE MANGEMENT FUNCTIONS====
//(preventing multiple copies being loaded etc)
...
//====UTILL FUNCTIONS====
//getting texture details, etc
...
//====OVERLOADED OPERTORS====
....
В значительной степени используйте этот подход для чего-либо, в чем я кодирую. Хорошая структура и хорошо прокомментировала, что код делает хорошее чтение
- Глобальные переменные
- Функции
- Основное Тело/Метод
Мне нравится сохранять вещи простыми, таким образом, я не наполняю набор методов в классе. В классе я обычно имею обычно используемый (или измененный я ;-)) методы, перечисленные сначала. Насколько определенная организация кода идет, каждый набор методов принадлежит классу, таким образом, она организует отдельно.
Я использую функцию поиска своего редактора и код, сворачивающийся для навигации через большие исходные файлы. Точно так же я использую функции поиска для нахождения вещей в других контекстах также. Главная организационная схема никогда не подходила мне, таким образом, я полагаюсь на питание поиска во всех вещах, не просто кодируют.
Я склонен группировать вещи тематически из-за отсутствия лучшего слова.
Например, если бы у меня был открытый метод, который использовал два закрытых метода в ходе выполнения его работы затем, то я собрал бы в группу все три в файле реализации, так как разногласия хороши, что, если Вы собираетесь быть рассмотрением одного из них затем, необходимо будет посмотреть на одного из других.
Я также всегда группа добираюсь/методы установки для конкретного участника класса.
Это - действительно персональное предпочтение, особенно с современными IDE, так как существует много функций, которые позволяют Вам автоматически переходить к местоположениям в коде.
общественность, защищенная и затем частная и в каждом разделе в алфавитном порядке, хотя я часто перечисляю конструктора сначала и deconstructor в последний раз.
/Allan
Интересный момент. Я действительно не думал об этом.
Я склонен помещать часто полученные доступ функции наверху (служебные функции и такой), поскольку они - наиболее вероятная тонкая настройка потребности.
Я не думаю, что организация особенно важна, поскольку я могу найти любую функцию быстро. Я не просматриваю свой файл путем прокрутки для нахождения функции; я ищу его.
В C++ я действительно ожидаю, что функции в .cpp файле находятся в том же порядке, в котором они объявляются в.h файле. Который обычно является конструкторами, сопровождаемыми деструкторами, сопровождаемыми основными/центральными функциями функциональности, сопровождаемыми служебными функциями.
Я главным образом пишу код C, и я склонен заказывать зависимостью. Если возможный я пытаюсь соответствовать своему файлу исходного кода мне заголовочные файлы, но обычно это - если пусто () использует интервал b (символ *нечто), чем интервал b (символ *нечто) на первом месте.
Сохраняет меня от добавляющих записей до заголовочного файла для локальных функций.
Для остальных это главным образом алфавитно на самом деле, делает поиск легче.
У меня есть все частные поля, затем общественность, затем конструкторы, затем основное, затем методы, которыми основными вызовами, в порядке их называют.