Work You Can Explain Practical AI, computing, and learning for students

Stop Naming Files “Final-Final-2”

Build a predictable filename convention and know when filenames, document history, or Git should manage revisions.

By Ian Fang Beginner 15 minutes
A student-centered editorial illustration representing Stop Naming Files “Final-Final-2”.

essay-final-final-2.docx does not tell you which copy is editable, which one a classmate reviewed, or which one you submitted. It records a sequence of uncertain decisions in a place that should identify the file.

Use a stable descriptive name. Add a sortable date or meaningful state only when it answers a real retrieval question. Keep one clear editable source, and use document version history or Git when the work needs actual change history.

A filename should identify the artifact

A useful filename helps a person answer:

  • What is this?
  • Which course or project owns it when the folder context is insufficient?
  • Which date or state matters?
  • What format is it?

For example:

biology-lab-03-enzyme-activity.docx

The course folder may already supply biology, so a shorter name can be enough:

lab-03-enzyme-activity.docx

Do not repeat every folder name in every filename. Include enough context for the file to remain recognizable when downloaded, attached, or submitted.

Use dates when time identifies the item

Write dates from largest unit to smallest:

2026-10-08-advising-notes.md

The YYYY-MM-DD order sorts chronologically in an ordinary filename listing and avoids ambiguity between month-first and day-first numeric dates.

A date is useful for meeting notes, periodic exports, snapshots, and submitted records. It is often unnecessary for one continuously edited source file. Adding today’s date every time you save creates another manual version system.

If the date represents something specific, say what it means in your convention: meeting date, observation date, export date, or submission date.

Use states with defined meanings

Words such as new, latest, and final lose meaning as soon as another revision appears. Prefer a small vocabulary whose transitions you can explain:

research-proposal-draft.docx
research-proposal-for-review.pdf
research-proposal-submitted-2026-10-08.pdf

Possible states include:

  • draft: the active editable work, not ready for delivery;
  • for-review: a copy intentionally sent for comments;
  • approved: formally accepted in a workflow that defines approval; and
  • submitted: the exact copy delivered through a course system.

Do not create a new file for every state automatically. One editable source can move from draft to ready while its history remains in the document system or Git. Export a separate review or submission copy when preserving that exact state matters.

Keep one canonical editable source

When several files can all be edited, uncertainty grows:

lab-report.docx
lab-report-new.docx
lab-report-fixed.docx
lab-report-final-final-2.docx

Choose one canonical source:

lab-report.docx

Store meaningful prior states in the version history provided by an authorized collaboration system, or in Git when the files and workflow fit line-oriented version control. Preserve an exact exported submission separately:

lab-report-submitted-2026-10-08.pdf

The source answers “what do I edit?” The submitted copy answers “what did I deliver?” A receipt or confirmation answers “was it received?” No filename can prove submission by itself.

Choose the right level of versioning

Filenames are enough for a few deliberate snapshots

Use filenames when you need a small number of independent records and no system already maintains trustworthy history. Examples include monthly exports or copies supplied to different reviewers.

Avoid v2, v3, and v7 unless your workflow defines what increments the number and where the change is recorded. A version number without a change record often recreates the same uncertainty as final-final.

Document history fits collaborative rich documents

Word processors and cloud document systems can preserve revisions, comments, and named versions. Use an institutionally authorized system when collaboration, tracked review, or required formatting makes it appropriate.

Check what the system actually retains, who can access it, and how to export the editable file and necessary history. Version history is not automatically a backup, and institutional access may end.

Git fits line-oriented project history

Git is useful when source text, code, configuration, and documentation change together. Commits can group related changes and record why they were made.

Git is not required for every essay, and it does not make vague names harmless. Large or frequently changing binary documents may not produce useful ordinary diffs. Later posts in this series explain what Git tracks and how to make a useful commit.

Write a personal filename convention

Start with five rules:

# My Filename Convention

1. Use lowercase descriptive words separated by hyphens unless a course
   requires another format.
2. Keep the official assignment number when it helps match the syllabus.
3. Use YYYY-MM-DD only when the date identifies a meeting, export, or submitted
   record.
4. Keep one canonical editable source.
5. Use the suffixes draft, for-review, and submitted only with the meanings
   defined below.

Add your state definitions and exceptions. Course submission instructions override a personal preference. Some systems reject particular characters or require a student ID; follow the authorized rule while avoiding unnecessary sensitive information.

The exact choice of hyphens, underscores, or capitalization matters less than consistent, documented use. Prefer characters that work across the systems you actually use, and test before renaming active project files.

Practice on safe copies

Create a practice folder containing:

biology-lab-final.docx
biology-lab-final-new.docx
biology-lab-final-final-2.docx

Do not use real active coursework. Decide which practice file represents the editable source, which represents a review export, and which represents the submitted copy. Rename them according to your convention.

Then verify:

  1. Can you identify the editable file without opening it?
  2. Can you identify the exact submitted record?
  3. Does the submitted date have a defined meaning?
  4. Is any duplicate unnecessary?
  5. Would a version-history system make one of these copies redundant?

Delete nothing until you have checked the contents. Similar names do not prove that files are identical.

Common mistakes

  • Using final as a permanent state. New feedback immediately makes it ambiguous.
  • Adding dates to every save. Dates should identify meaningful events, not replace history.
  • Putting sensitive data in names. Filenames can appear in search results, attachments, logs, and shared screens.
  • Renaming active project files casually. Links, code, and collaborators may depend on the existing path.
  • Assuming sync provides version control. Synchronization can propagate a mistaken rename or deletion.
  • Keeping only the submitted PDF. Preserve the editable source and required supporting material.

Do this now

Write your five-rule convention and test it on the practice files. Check a current course’s submission rules and add one explicit exception if needed. Do not reorganize active work immediately before a deadline.

Log what you learned

Record only:

  • Result: What did the action produce?
  • Evidence: What observation, test, or source supports that result?
  • Next action or unresolved question: What should happen next?

The next post separates three protections that are often confused: synchronization, Git, and backup.