Which of the Following Is Accurate Regarding Conventions for File Naming?

The answer

The accurate file-naming conventions are the ones that make files consistent, sortable, and machine-readable. A correct option will say something like: avoid spaces and special characters, use hyphens or underscores as separators, write dates as YYYY-MM-DD, and keep names short but descriptive. Any option claiming that spaces are fine, that names should be as long as possible, or that dates should be written MM/DD/YY is inaccurate.

Good conventions exist because file names are read by both humans and software. If they break for either audience, work is lost, links fail, and files sort in a useless order.

The core rules

• No spaces. Spaces break in URLs (they become %20), require quoting in command lines and scripts, and can confuse older systems. Use an underscore (report_final) or hyphen (report-final) instead.
• No special characters. Avoid / \ : * ? " < > | & $ # and similar. Several are reserved by operating systems for paths and wildcards; a file named sales:2024 may be impossible to save on Windows.
• Use ISO 8601 dates: YYYY-MM-DD. Written this way, dates sort chronologically when sorted alphabetically, because the largest unit (year) comes first. 2026-07-15 always lands in the right place; 07-15-26 and 15/07/2026 do not, and they are ambiguous across regions.
• Most important information first. Front-load the element you will scan or sort by (project name, date, or ID), because file listings sort left to right.
• Leading zeros for sequences. Use chapter-01, chapter-02 ... chapter-10, not 1, 2, 10. Without the zero, alphabetical sorting puts 10 right after 1.
• Short but descriptive. Long enough to identify the file without opening it, short enough to stay well under path-length limits and remain readable.
• Be consistent across a whole project — pick one separator and one date format and stick to them.

Why the other options are wrong

An option that says "spaces make names easier to read, so use them freely" is wrong: readability inside one folder is not worth breaking URLs, scripts, and cross-platform compatibility — that is exactly what underscores and hyphens solve. An option praising MM/DD/YYYY or DD-MM-YYYY dates is wrong because slashes are illegal in file names and those formats do not sort chronologically. An option saying "longer names are always better" is wrong because overly long names hit path limits and get truncated. And "special characters help organize files" is wrong — they are reserved characters that cause errors.

The bigger picture

These conventions come straight from research-data management guides used by universities and standards bodies. The underlying goal is future-proofing: a file you or a program can find, sort, and open years later, on any system, without guesswork. When in doubt, apply the test — would this name still work in a URL, a script, and an alphabetical sort? If yes, it follows the conventions.