Abstract

I will explore the significance of hyphens and underscores in BIM file naming conventions, emphasizing their importance for clarity, readability, and compliance with international standards. I will discuss ISO 8601’s date format for chronological sorting, ISO 9660’s file system constraints, ISO 13567’s CAD layer naming standards, and ISO 19650’s structured naming for BIM projects. These standards promote interoperability, ease of search, and consistent organization of project information across various platforms and disciplines. By adhering to these conventions, teams can reduce confusion, enhance collaboration, and ensure that project data remains accessible and unambiguous.

ISO Standards for Hyphen and Underscore Usage

ISO 8601 Date and time — Representations for information interchange

This international date format standard prescribes a numeric year-month-day format (e.g. YYYY-MM-DD). Using ISO 8601 dates in file names is widely considered best practice for chronological sorting and clarity (File Naming Best Practices Sharepoint Online | Restackio) (File Naming Conventions | Data Management). For example, a date like March 4, 2025 would be written 2025-03-04, which ensures that files sort in true date order when listed alphabetically (File Naming Conventions | Data Management). Consistent use of this format in file names (for creation or revision dates) avoids ambiguity and makes it easy to identify the latest files at a glance. This format is preferable over the DD/MM/YYYY format because it allows for straightforward and accurate sorting by year, month, and day, without any confusion. ISO 8601-1:2019 - Date and time — Representations for information interchange — Part 1: Basic rules - https://www.iso.org/standard/70907.html

Table A.1 - Calendar date - 12 April 1985

Table A.9 - Local time of day - 27 minutes and 46 seconds past 15 hours

ISO 9660 Information processing — Volume and file structure of CD-ROM for information interchange

This standard (originally for CD-ROM file systems) introduced strict limitations on file name length and characters to maximize cross-platform compatibility. Under ISO 9660:1988 Level 1, file names were limited to 8.3 format and could only use letters A–Z, digits 0–9, and the underscore (_) character (CDRoller Technology - Data Recovery from CD, DVD and Blu-Ray Discs). (Hyphens were not included in the most restrictive ISO 9660 character set, though later extensions allowed (-) along with other symbols (CDRoller Technology - Data Recovery from CD, DVD and Blu-Ray Discs).) The influence of ISO 9660 can be seen in many file naming policies that avoid spaces and most punctuation. In practice today, modern operating systems handle a wider range of characters, but many organizations still restrict file names to alphanumeric characters, underscore, and hyphen for safety and interoperability. ISO/IEC 9660:2023 - Information processing — Volume and file structure of CD-ROM for information interchange - https://www.iso.org/standard/81979.html

ISO 13567-2 Technical product documentation — Organization and naming of layers for CAD

In addition to file naming conventions, ISO 13567 defines a standardized approach to CAD layer naming for organizing drawing data in a structured and consistent manner. This standard prescribes a layer naming system using alphanumeric codes separated by hyphens (-), similar to ISO 19650's file naming approach. Each layer name is built from a series of structured fields—typically including discipline, element type, and presentation details (e.g., A-ROOF-____-OTLN for architectural roof outlines). The use of hyphens ensures that each field remains distinct, making it easy to filter and search for layers within CAD software such as AutoCAD, Civil 3D, and Revit. The hyphen separator is preferred over underscores in this context because it improves readability and aligns with international CAD and BIM standards. By following ISO 13567, design teams maintain consistent, logical layer structures across projects, reducing confusion and improving collaboration between disciplines. ISO 13567-2:2017 - Technical product documentation — Organization and naming of layers for CAD — Part 2: Concepts, format and codes used in construction documentation - https://www.iso.org/standard/70182.html

Layer name mapping according to ISO 13567 in Revit

ISO 19650-2 Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling

ISO 19650 (an international BIM standard, derived from the UK’s BS 1192) adapts the above principles into a structured naming convention for project information. It defines standardized fields in a file name (often called an “information container” in BIM) such as Project, Originator, Zone, Level, Document Type, Role, and Number. These fields are typically separated by hyphens according to the ISO 19650 guidelines. For example, a file name might look like:

Project_Code-Originator-Zone-Level-Document_Type-Role-Number.ext

Figure B.1 - Container naming in the common data environment

Each hyphen-delimited segment carries meaning (project identifier, who created it, what it is, etc.), making complex file names easier to parse. ISO 19650 (and its related national standards) explicitly prescribes using the hyphen (-) as the delimiter between fields (BIM Object Naming Convention). If a particular field itself needs a secondary separator (e.g. a document sub-type or a compound title within one field), an underscore is used for that purpose (BIM Object Naming Convention). In other words, hyphens separate major fields, and underscores separate sub-components within a field in the naming scheme.

Only a limited character set is allowed to ensure compatibility. As one BIM standard notes: “Only the letters (A–Z), hyphen (-), underscore (_) and numbers (0–9) shall be used” in CAD/BIM file names and related object names (BIM Object Naming Convention). Spaces and other special characters are prohibited (BIM Object Naming Convention). This mirrors the ISO 9660 safe set and prevents issues when transferring files between systems. ISO 19650-aligned naming also recommends including dates and revisions in controlled ways. For instance, a work-in-progress file that hasn’t been allocated a formal document number might include a date stamp in ISO 8601 format (YYYY-MM-DD) as part of the name. Revision or version codes are often appended at the end, typically separated by an hyphen (e.g. -V1 or -1.0). All these practices aim to make BIM file names self-descriptive, uniquely identifiable, and sortable, in line with ISO standards. ISO 19650-2:2018 - Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 2: Delivery phase of the assets - https://www.iso.org/standard/68080.html

ISO 9001 Quality management systems — Requirements

Under ISO 9001, organizations must control documents to ensure quality processes are followed. While ISO 9001 doesn’t prescribe exact file naming rules, it requires that documents be readily identifiable and kept up-to-date (Document naming convention ISO 9001, how to label your documents? - ISO 9001 CONSULTANTS) (ISO document management and compliance with standards). A structured file naming convention is a practical way to meet this need. It brings consistency, making it easy for staff to find the right documents and avoid using outdated versions. In a well-designed naming scheme, file names are:

Consistent and Descriptive – Using a standard vocabulary and format for names makes files “meaningful” to users and allows anyone to understand the content without opening it (File Naming Conventions and Version Control | Princeton University Records Management). For example, a policy document might always start with POL- and a procedure with PRO- as a prefix, followed by a brief topic description.
Uniquely Identifiable – Including key metadata (like project, department, or document type codes) in the name ensures each file is distinct. ISO 9001 encourages using reference codes or numbering systems so that documents remain identifiable and legible (Document naming convention ISO 9001, how to label your documents? - ISO 9001 CONSULTANTS). For instance, “SOP-Quality-001” could denote Standard Operating Procedure #001 for the Quality department.
Traceable and Versioned – Good naming conventions improve traceability by embedding version numbers or dates. This helps users instantly recognize the latest approved file. Using a version indicator (e.g., -v1, -v2) or a revision date in YYYY-MM-DD format supports ISO 9001’s emphasis on revision control (File Naming Conventions and Version Control | Princeton University Records Management). As an example, WorkInstr_Calibration_v3.doc shows it’s version 3 of a work instruction, aligning with the requirement to track revisions.
System-Friendly – ISO 9001 documentation is often managed in electronic systems, so file names should avoid problematic characters. No spaces or special symbols are used; instead, hyphens (-) or underscores (_) separate words (Document Management System Best Practices for File Naming Conventions - Document Management System Folderit). This ensures compatibility across platforms and helps automated document management systems parse the name into meaningful parts.

Choosing hyphens or underscores as separators in file names may seem trivial, but it can impact consistency and clarity. Many organizations opt for the hyphen (-) to delineate different data fields in the file name (BS1192/ISO19650 compatible Class Libraries - Update - General Discussion - Vectorworks Community Board). The hyphen is visually clean and commonly understood as a word separator. For example, a quality manual section could be named QM-01-Introduction.pdf, where each hyphen separates the document type, section number, and title. Using hyphens in this way improves readability and lets each segment of the name carry specific meaning (e.g. QM for quality manual, 01 for section number) (BS1192/ISO19650 compatible Class Libraries - Update - General Discussion - Vectorworks Community Board). Some guidelines even reserve hyphens exclusively for separating defined fields in a name, to avoid any confusion (07. File Naming - ISO 19650 UK Annex - Edocuments Support).

Including dates in file names is a best practice for quality management documents, as it immediately signals timing and helps in sorting files chronologically (Document Management System Best Practices for File Naming Conventions - Document Management System Folderit). Under ISO 9001, documents and records often need to show when they were created or updated (for example, the date of last revision on a procedure). Using the ISO 8601 date format – which is YYYY-MM-DD or a similar numeric year-month-day order – is highly recommended for this purpose. This format is unambiguous and sorts naturally. For instance, files named Audit_Report-2023-09-15.pdf and Audit_Report-2023-12-01.pdf will automatically list in date order, whereas a format like MM-DD-YYYY could misorder if used inconsistently. ISO 8601 dates also avoid confusion between regions (no mix-up of day/month order) (Document Management System Best Practices for File Naming Conventions - Document Management System Folderit).

Building Information Modeling (BIM) projects generate huge numbers of documents and drawings, so implementing ISO 9001 document control often goes hand-in-hand with structured naming conventions. A notable example comes from the architecture/engineering/construction industry: the ISO 19650 standard for BIM information management. Many firms align their BIM documentation practices with ISO 9001 principles by using the ISO 19650 naming system, which enforces a very structured file name format (Implementing a BIM numbering system | CQI | IRCA). ISO 19650 (formerly BS 1192 in the UK) defines an 8-part file name schema covering project, originator, location, purpose, etc., each separated by hyphens (07. File Naming - ISO 19650 UK Annex - Edocuments Support). This kind of rigor in naming was originally developed to ensure every drawing and document on a project is uniquely and systematically identified – a clear parallel to ISO 9001’s requirement for controlled, identifiable documents.

Companies implementing BIM have found that such naming standards improve efficiency and quality. Hook Architects, for instance, adopted ISO 9001-style document control early in their BIM journey. They collaborated with a project management firm that applied ISO 9001 standards for document control, which highlighted “the benefits of structured document management” in practice (Case study for Hook Architects-18sep24). This experience inspired them to pursue ISO 19650 certification for BIM, essentially building on their ISO 9001 foundation to handle the specialized needs of construction information (Case study for Hook Architects-18sep24). The result is a BIM workflow where every model, drawing, and report is managed with the same discipline as any ISO 9001 quality document – named systematically, versioned, and controlled through a common data environment. The Common Data Environment (CDE) itself, a central repository in BIM projects, relies on consistent file naming to automate workflows like approvals and revisions. In summary, by extending ISO 9001-compliant naming conventions into BIM, companies ensure that even in complex projects, information remains organized, easily traceable, and ready for quality audits or handover to clients.

ISO 14001 Environmental management systems — Requirements with guidance for use

ISO 14001 requires similar discipline in document control, but with focus on environmental management records. The standard expects that EMS (Environmental Management System) documents and records are properly controlled – they must be legible, dated, readily identifiable, and maintained in an orderly manner. In practice, this means environmental policies, procedures, monitoring data, and reports should all follow a consistent naming and filing system, much like quality documents under ISO 9001. A structured file naming convention greatly facilitates compliance here: it helps ensure that required records (like training logs, inspection reports, permits, etc.) can be quickly found and verified during audits. It also reduces the risk of misplacing critical information needed to demonstrate environmental performance or legal compliance.

Hyphen vs. Underscore Across Key BIM Platforms

Modern BIM workflows involve various platforms and software. The handling of hyphens (-) vs. underscores (_) in file names can vary slightly across these systems, though both characters are generally supported.

Autodesk Construction Cloud (ACC/BIM 360)

ACC allows project admins to enforce a naming standard. In fact, it provides a built-in ISO 19650 template that uses hyphens as the default delimiter between naming fields. The system lets you choose a delimiter (options typically include hyphen, underscore, or period) when configuring naming rules (DOCS Help | Create Naming Standards | Autodesk). In an ISO 19650-based setup, hyphens will be used to separate the fields (project, discipline, etc.) in file names, consistent with the standard. Both hyphens and underscores are valid characters in ACC file names, and the platform’s search/sort will treat them as normal characters (there’s no special handling difference in simple name sorting). In practice, BIM teams using ACC usually stick to hyphenated file names to comply with the ISO 19650 convention and because Autodesk’s tools (Revit, Civil 3D, etc.) integrate well with that format.

Autodesk Construction Cloud ACC - ISO 19650 Naming Convention

Microsoft SharePoint Online

SharePoint, often used for document management, also accepts both hyphens and underscores in file names. Microsoft’s general guidance is to avoid spaces (since they turn into %20 in URLs) and to use clear delimiters like hyphens or underscores instead (SharePoint naming conventions | TECHTRON). Some SharePoint best-practice guides explicitly encourage hyphens for readability – e.g. naming files like project-report-2023.docx rather than projectreport2023.docx (File Naming Best Practices Sharepoint Online | Restackio). Hyphens visually separate words, which can help users identify the file content quickly. However, there is also a school of thought favoring underscores in SharePoint: one expert notes that hyphens in URLs can sometimes cause line-break issues in emails and are used by browsers as breakpoints, whereas underscores do not break and are slightly less likely to be misinterpreted in links (SharePoint naming conventions | TECHTRON). Many organizations using SharePoint for BIM documents have gravitated toward hyphenated conventions (often matching the ISO 19650 style they use elsewhere) for consistency.

%7D&file=Document%20File%20Name.docx&action=default&mobileredirect=true

%7D&file=Document-File-Name.docx&action=default&mobileredirect=true

%7D&file=Document_File_Name.docx&action=default&mobileredirect=true

Autodesk Revit (and other design tools like AutoCAD Civil 3D/AutoCAD)

These authoring tools rely on the operating system (Windows) for file handling, so they permit both hyphens and underscores in file names without issue. Revit project files (.RVT), family files (.RFA), and template files (.RTE) can all be named with alphanumeric and separator characters freely. Leading BIM firms usually apply the same project naming convention to Revit models as to other files – meaning a Revit file will often follow the ISO 19650 pattern (hyphenated codes) rather than an ad-hoc naming. For example, a structural model file might be named ABCD-STR-ZZ-M3-X-0001.rvt following the project’s container naming standard (where each segment has meaning) (Revit - File Naming – Arkance Systems UK). Revit itself doesn’t enforce this, but project standards do.

Within Revit, some users have preferences for underscores in certain contexts: e.g. Revit family names or layer/export names might use underscores or CamelCase internally for readability. There is a caution that if a file name (or family name) with a hyphen is used inside Revit formulas or in scripting, it could be interpreted as a minus sign. In fact, one open BIM standard advises avoiding the hyphen character because it can cause errors when a name is used in formulas (the hyphen might be read as a subtraction operator) (2.0 Naming Conventions - Masterspec). This is more about object naming or parameters than file names, but it’s worth noting. In practice, Revit file names rarely need to be parsed as formulas, so this is not a common problem.

For pure file naming of Revit models and drawings, hyphens are predominant in ISO-aligned workflows, and Revit handles them fine. AutoCAD and Civil 3D likewise accept both characters; historically many CAD users used underscores to replace spaces (e.g. Site_Plan.dwg) or used hyphens in layer names (the classic ISO 13567 layering standard uses hyphens). There’s no technical limitation in these tools that would force one or the other – it comes down to the naming convention in use. If following an ISO 13567 and ISO 19650 scheme, then DWG files, RVT files, etc., will naturally have hyphens as separators.

In CAD workflows (e.g., AutoCAD, Civil 3D), project files are commonly organized into individual drawing files (DWG, DXF), each representing clearly-defined entities such as model files, views, sheets, and external references. Often, these individual files follow a structured naming convention using hyphens for clear, readable segmentation, in line with industry and ISO standards: each field clearly indicates project, discipline, zone, type, and numbering, all separated with hyphens.

In contrast, Revit stores multiple views, sheets, and schedules internally within a single RVT project file, accessible through the Revit Project Browser. It is important to note that in Autodesk AutoCAD or Civil 3D, each separate drawing sheet (layout) or view typically exports as its own independent DWG or DXF file, adhering to the established hyphen-separated naming convention. To ensure consistency across these platforms, the internal naming of views and sheets within the Revit Project Browser should ideally conform to the hyphen-based external file naming strategy. Adopting a consistent naming convention for Revit views, sheets, schedules, and other project elements is essential for clarity and compliance. Industry standards such as BS1192 (now superseded by ISO 19650) mandate the use of hyphens (-) to separate distinct fields of information, and underscores (_) to separate components within those fields. In practice, this means avoiding spaces or other special characters in names, and structuring names into ordered segments (fields) that communicate specific information. This approach ensures that names are self-explanatory and remain compatible across different software platforms. bimuk.co.uk support.edocuments.co.uk

Example of a Unified Naming Convention:

External CAD files Views and Sheets:

01-FloorPlan.dwg
OHPR1-ARC-01-FloorPlan.dwg
02-FoundationLayout.dwg
OHPR1-STR-02-FoundationLayout.dwg

Internal Revit Browser Views and Sheets:

01-FloorPlan
OHPR1-ARC-01-FloorPlan
02-FoundationLayout
OHPR1-STR-02-FoundationLayout

This maintains consistency throughout, bridging the gap between internal Project Browser labeling in Revit and external CAD file management.

Microsoft Excel

Excel file names (e.g. .xlsx spreadsheets) follow the same rules as any Windows file – hyphens and underscores are both allowed. Many organizations include dates or version numbers in Excel file names, and here the ISO 8601 format is helpful (for instance, Project_Budget-2025-03-04.xlsx or Project_Budget-20250304-v2.xlsx). Excel itself does not care which delimiter is used; however, if one Excel file references another (through formulas linking workbooks), having a space or special symbol in the target file’s name can complicate the formula (Excel will quote file names with spaces or some characters). Hyphens and underscores are benign and won’t break formulas – they appear as is in the reference path. So from Excel’s perspective, both are equally fine for file naming. One minor note is that Excel (and Windows) will show file names underlined as hyperlinks in some cases (e.g. an email or Word document). In underlined text, an underscore character can “disappear” into the underline, whereas a hyphen remains visible. This affects visual clarity when sharing file names/links in communications, but not the functionality. As for sorting, Excel will list files in the order provided by the OS (which is usually alphabetical/numerical). If files are named with dates or numbers, including hyphens doesn’t disrupt the sort. For example, 2024-12-01... will correctly sort before 2025-01-01... lexicographically (File Naming Conventions | Data Management). In summary, Excel users typically choose whichever delimiter matches the project’s naming convention; there’s no special advantage within Excel itself to using one over the other beyond general readability considerations.

When using Excel files to organize data where the file names themselves contain structured data fields, establishing a consistent delimiter hierarchy becomes crucial. If your file names need to represent multiple data fields (such as project codes, departments, dates, and versions), you should implement a systematic approach to separators:

Use hyphens (-) as primary field separators to distinguish major data containers
Use underscores (_) for sub-data elements within those fields

For example, a financial spreadsheet might be named:

Project_Code-Department-Region-2025-03-18-Q1-Final_Version.xlsx

This hierarchical approach creates a visual distinction between major data fields (separated by hyphens) and their subcomponents (separated by underscores). The clear separation improves readability and facilitates both manual searching and automated parsing of file names.

For organizations that manage large datasets where Excel files serve as data containers, this approach can be incorporated into formal naming standards. A consistent implementation across teams ensures that everyone can quickly identify file contents without opening them, while also supporting automated file management processes. https://www.queensu.ca/accessandprivacy/guidance/file-naming-standards

Other Platforms (Dalux, Catenda, etc.)

Other BIM collaboration platforms like Dalux, Catenda, etc., generally follow similar patterns – they allow hyphens and underscores, and often promote using a consistent naming convention for projects. They may not enforce one by default, but teams often carry over their standard (ISO 19650 or otherwise) into these systems. The Windows file system (NTFS) supports both (_) and (-). Windows Explorer sorting is essentially lexicographic; in ASCII sorting order, the hyphen (ASCII 45) comes before the underscore (ASCII 95). This means if you had a mix of hyphenated and underscored names, they might not intermix intuitively – e.g. "Alpha-file" might sort before "Alpha_file" due to the hyphen’s code. However, in a real BIM project, you wouldn’t normally mix conventions in the same folder – you’d pick one style and all files follow it, so sorting is consistent. Windows, by default, is case-insensitive and treats both characters as word separators for double-click selection. There is no issue opening or saving files with either character. One just has to avoid characters like / \ : * ? " < > | which Windows forbids (neither hyphen nor underscore pose a problem here).

User Efficiency: Typing, Selecting, and Reading File Names

The choice of (-) vs. (_) can affect user efficiency in subtle ways:

Typing and Keystrokes

On a standard QWERTY keyboard, the hyphen is a direct key press, whereas typing an underscore requires holding (Shift + -). Thus, every underscore involves an extra key stroke and a bit more finger movement. Over hundreds of file naming operations, this can add slight friction. Some BIM coordinators note that hyphen is faster to type and less error-prone (no chance of accidentally hitting another key while holding Shift). This is a small factor, but for speed of text entry, hyphen has the edge. (One Autodesk forum commenter even argued underscores are preferable in family names specifically because a hyphen might be misinterpreted in code as a minus sign (hyphens vs underscores in family naming - Autodesk Forums), but that’s a niche computing concern; for pure typing effort, avoiding the need for Shift is the main advantage of (-).)

Mouse Selection (Double-Click Behavior)

Perhaps the most noticeable UI difference is how words separated by hyphens or underscores get selected. In many interfaces, a hyphen is treated like a space or word boundary, while an underscore is treated as a regular character within a word. Double-clicking on a file name (or any text) that contains hyphens will typically select only the chunk up to the hyphen. For example, given the name Project-Report-Final.pdf, a double-click on “Report” will highlight just “Report” (since - ends the selection). In contrast, in a name with underscores like Project_Report_Final.pdf, a double-click on any part of “Project_Report_Final” will usually select the entire Project_Report_Final string as one unit. In effect, underscores cause the whole string to be selected, whereas hyphens let each word be highlighted individually. This has pros and cons for efficiency: if a user wants to quickly copy the entire file name or rename the whole thing, underscores allow one-click selection of it all. But if the goal is to edit or replace just one part of the name (say, change “Final” to “RevA”), the hyphen-separated format makes it easy – just double-click the relevant segment and edit it, without disturbing the other parts. With underscores, the user might have to carefully click and drag to select just that portion or move the cursor with arrow keys, which is a bit more effort. Many power-users exploit the double-click behavior to speed up renaming: with hyphens, they can update a date or version code by selecting that token alone. With underscores, they might end up selecting too much and have to re-select. In summary, hyphens optimize partial selections, while underscores optimize full-name selections ([NodeJs-신입]2일차 - 개발환경설정- II편( ver 22.09.01) :: Pre Stage). Depending on whether users more frequently rename parts of file names or copy whole names, this can influence preference.

ProjectCode-Originator-Zone-Level-DocumentType-Role-Number

Table - Comparing Double-Click Selection

Keyboard Navigation

Similar to the above, when using keyboard shortcuts to jump between words (e.g. Ctrl+Left/Right in text editing), hyphens act as separators. This means you can jump cursor position to the start of each word in a hyphenated file name quickly. Underscores, on the other hand, bind the words, so the cursor would treat the entire underscored sequence as one word. Again, if editing one segment of a name, hyphens can reduce the number of arrow key presses needed to get there. If using a tool or script to batch-rename, the difference is negligible – scripts can handle either character – but for manual renaming tasks, users often find hyphen-delimited names more convenient.

Readability

Both hyphens and underscores improve readability of multi-word file names significantly compared to having no separator or using a run-on CamelCase string. That said, there are subtle differences. Hyphens tend to be visually lighter and at the mid-line of text, which many find makes the words flow like a normal phrase (e.g. “Project report 2023” -> Project-report-2023 is fairly easy on the eyes). Underscores draw a small line below the text, which can be less noticeable or, conversely, in some fonts, can make the words appear joined more tightly. One downside of underscores is when file names are shown in an underlined context (such as a hyperlink on a webpage or in an email): the underline can obscure the underscore character entirely, making Project_Report look like ProjectReport in print. Hyphens do not have that problem and remain visible in underlined links (SharePoint naming conventions | TECHTRON). On the other hand, underscores lack any semantic meaning in natural language, so seeing an underscore in a name doesn’t confuse it with a minus or a dash that might be part of the content. Most users, however, don’t mistake a hyphen in a file name for a minus sign – context makes it clear it’s just a separator. Overall, many consider hyphen-separated names slightly more readable as they mimic how we would hyphenate words or use dashes in sentences (File Naming Best Practices Sharepoint Online | Restackio). The difference is subjective, though – a neatly placed underscore can also be clear. Consistency matters more: a file naming scheme that uses the same delimiter throughout will be easier to scan. For instance, reading a folder where every file is like ABCD-EF-GH-001.pdf (all hyphenated segments) is cognitively easier because you know what to expect in each position, versus a mix like ABCD_EF-GH_001 which might slow recognition. In summary, hyphens offer a slight edge in human readability and don’t vanish in formatted text, whereas underscores visually group the name tightly (which some may find “cleaner” looking in plain text).

Sorting and Order

If the naming convention is well-designed (using zero-padded numbers, standardized dates, and consistent field lengths), files will sort logically whether hyphens or underscores are used. For example, using a date prefix YYYYMMDD or YYYY-MM-DD will sort chronologically either way (File Naming Conventions | Data Management). There is a minor technical difference in how sorting algorithms treat the characters: as noted, the ASCII code for hyphen is 45 and underscore is 95, so purely character-based sorting will place hyphen before underscore. In an alphabetical list, all else equal, Report-Alpha.pdf would come before Report_Alpha.pdf because (-) is "less than" (_). In practice, this only matters if you have a mix of conventions or you are comparing two otherwise identical names. Within a single project, you would typically not have two files named only by different delimiters. As long as the date or index numbers are in a fixed format, both separators will allow correct sequential ordering (e.g., file-01, file-02, ..., file-10 vs file01, file_02, ...). Modern file explorers also do “natural sorting” (treating numeric substrings as numbers), so the presence of a hyphen or underscore doesn’t alter that behavior. One scenario to note: if a naming scheme relies on a hyphen for a negative sign (unlikely for file names), that’s a different meaning – but in file naming, the hyphen is purely part of the string. In summary, sorting behavior is essentially neutral between (-) and (_) provided the naming scheme uses them consistently; the structured parts of the name (dates, numbers, etc.) will govern order far more than the choice of delimiter.

Industry Best Practices and Preferred Conventions

Leading BIM firms and project standards almost universally advocate for a consistent, structured naming convention – one that often aligns with ISO 19650 or its regional adaptations. Here are some best-practice insights from industry standards and top firms:

Allowed Characters

Limit file names to a small set of safe characters. Typically, letters (A–Z, a–z), numbers (0–9), the hyphen (-), and the underscore (_) are the only characters permitted (BIM Object Naming Convention). Other symbols (like & @ % # etc.) and spaces should be avoided because they can cause problems in URLs, scripts, or certain systems (BIM Object Naming Convention). This mirrors the old ISO 9660 restrictions and ensures compatibility. By sticking to hyphens and underscores as the only separators, you also avoid confusion – one standard notes “The only two special characters that should be used are (-) and (_)” (BIM Object Naming Convention).

Use of Hyphen vs Underscore

The consensus in project file naming (drawings, models, documents, etc.) is to use the hyphen as the primary separator between different fields of information (BIM Object Naming Convention) (Revit - File Naming – Arkance Systems UK). For example, a large engineering firm following BS 1192/ISO 19650 might name a drawing file: PRJ-ARC-ZZ-DRG-0001.pdf. Here each dash-separated code has a defined meaning (project, architect, zone not applicable, document type "DRG" for drawing, document number 0001). If further granularity is needed within a field, an underscore can be used. For instance, in some standards a document type and sub-type are combined like REP_GEN (for a general report) as one field, which would appear in the file name as PRJ-ENG-XX-REP_GEN-0002.docx with an underscore joining the type code to a subtype code. The key principle as stated in multiple guidelines: “Fields should be separated by a (-) and components within fields by an (_)” (BIM Object Naming Convention) This approach is explicitly set out in the UK BIM standards and adopted by many firms’ BIM Execution Plans.

File Type and Extension

The naming convention’s document type code often indicates the kind of file (drawing, model, report, etc.), but best practice is not to rely on the file extension alone to convey this. For example, a drawing might be a DWG or a PDF, but in both cases the file name could include DRG or a similar code to denote “drawing”. Similarly, a 3D model might include MOD or M3 in the name, a specification might include SPEC, a schedule might use SCH, etc., depending on the agreed code list. Leading firms maintain a list of abbreviations for document types as part of their standard. The file’s extension (like .DWG, .PDF, .RVT, .IFC, .DOCX, .XLSX, etc.) is of course kept at the end and never removed or altered (except by file versioning systems) (Revit - File Naming – Arkance Systems UK). One practice is to ensure there is only one dot in the file name, right before the extension, and not use periods in the rest of the name (Revit - File Naming – Arkance Systems UK) – this avoids confusion and helps systems accurately parse the extension.

Applicability Across File Types

The same naming convention (field structure and separators) is typically applied to all file types in a BIM project – whether it’s a Word document (DOCX), an Excel sheet (XLSX), a CAD drawing (DWG/DXF), a BIM model (RVT/IFC), a PDF, a BCF (issue report), etc. This uniformity means team members don’t have to juggle different naming rules for different formats. For instance, a PDF exported from a drawing will carry the same base name as the source DWG model, and a coordination IFC model exported from Revit will be named in line with the Revit file’s naming convention. Top firms often automate part of this process (e.g. ensuring that when a drawing is issued as PDF, the PDF file name matches the drawing’s document number and title codes). The use of hyphens as separators makes it easier to script such automation and to parse file names reliably. It’s also common to include a short descriptor or title as part of the name for human readability (often at the end of the name after the coded fields). When included, this descriptor is usually separated by a hyphen or underscore as well, and kept concise (for example: PRJ-STR-ZZ-MST-0001-SteelFrames.ifc where "SteelFrames" is a short title). However, some standards prefer to put longer descriptions in metadata rather than in the file name to keep names shorter.

Date and Versioning

Leading practices often incorporate versioning either in the file name or via a managed system. If done in the name, an underscore is commonly used just before the version number or date. For example, a work-in-progress model might be PRJ-ARC-ZZ-M3-0001_V3.rvt for version 3, or include a date like PRJ-ARC-ZZ-M3-0001_20250304.rvt for a snapshot dated 2025-03-04. The use of the ISO 8601 date format (either with hyphens or in compact form) is encouraged in such cases, and the delimiter (underscore) clearly separates it from the rest of the structured name. Firms with robust CDE (Common Data Environment) platforms sometimes omit version in the file name and use the system’s version control, but during coordination exchanges, dated file names using ISO 8601 help avoid confusion.

Consistent Separators

Almost every published BIM naming standard emphasizes consistency. Once a decision is made to use hyphens (and underscores within fields), that rule is followed everywhere. This consistency is more important than the actual choice of character in terms of avoiding errors. All team members should be clear on the convention. Many “leading BIM firm” standards actually align so closely with ISO 19650 that there’s little deviation – meaning hyphens are the de facto separator for nearly all project deliverables. Some organizations or national standards outside the ISO 19650 environment might choose a different scheme (for example, the New Zealand Masterspec standard chooses underscores between fields and avoids hyphens entirely to prevent any formula interpretation issues (2.0 Naming Conventions - Masterspec)). Such cases are the exception; globally, the hyphenated approach (with _ as a secondary delimiter) is most widespread for BIM files. If a firm does opt to use underscores as primary separators, the key is that they apply it universally and be aware of the search/selection implications discussed earlier. In practice, even those who prefer underscores (for internal reasons) still disallow spaces and other characters, meaning the overall philosophy of “clean” file names is consistent across the industry.

Conclusion

Fields should be separated by a (-) and components within fields by an (_).
Letters (A–Z, a–z), numbers (0–9), the hyphen (-), and the underscore (_) are the only characters permitted.
The Revit internal project browser should adhere to the same file naming conventions as those applied to separate AutoCAD, Civil 3D, Word, Excel, and other project files.
Sort files by date using the YYYY-MM-DD format (ISO 8601).
Consistency in file naming across all platforms ensures ease of access and minimizes the risk of misplacing or misidentifying documents. This structured approach enhances collaboration and ensures all team members can efficiently locate and utilize project files.
If Common Data Environment (CDE) platforms, such as Autodesk Construction Cloud or Microsoft SharePoint, have built-in versioning capabilities, it is recommended not to include versions and dates in file names. These details should only be added when transferring data from one CDE to another, as the object becomes disconnected from its original data environment. This additional metadata ensures smooth integration into the new CDE platform.

Hyphen vs. Underscore in ISO, CAD, BIM File Naming Conventions