Files, Folders and a Workspace That Works

A file system is the scheme the operating system uses to lay out files on a drive and remember where each one is: NTFS on Windows, APFS on macOS, ext4 on most Linux systems, exFAT on memory cards meant to work with everything. On top of that scheme sits a tree of directories (folders), and a path is the set of directions from some starting point to a particular file.

The part after the last dot is a hint for the operating system about which program should open the file. It is only a hint. What actually determines the type is the content, and most formats start with a signature — a fixed sequence of bytes near the beginning. A PNG begins with a specific eight-byte header; a ZIP archive begins with the letters PK. Renaming a file from .png to .jpg changes nothing about the pixels inside it; it just makes programs guess wrong. Converting a file means re-encoding the data, which is a different operation entirely.

// File must be named Sorter.java - capital S, exact spelling.
public class Sorter {
    public static void main(String[] args) {
        System.out.println("ready");
    }
}
// Saved as sorter.java, the compiler reports:
//   class Sorter is public, should be declared in a file named Sorter.java

A good file name answers three questions without being opened: what is this, which version is it, and when was it made. Computers sort names as text, one character at a time, which has two consequences most people discover the hard way. Dates written as 2026-03-09 sort into true chronological order; dates written as March 9 2026 do not. And numbers sort as text too, so lab10 comes before lab2 unless you zero-pad it as lab02.

• No spaces. Use hyphens or underscores. Spaces force quoting on the command line and break URLs and some tools outright.
• Dates as YYYY-MM-DD. This is the ISO format, and it is the only common date layout that sorts chronologically as plain text.
• Zero-pad numbers. unit03-lab02.java, not unit3-lab2.java, so the tenth item does not jump ahead of the second.
• Be descriptive, then consistent. array-sort-bubble.java tells you what it is; test2final.java tells you nothing a week later.
• Avoid ? * : / \ < > | and accented characters. Several are illegal in file names on at least one operating system, and they cause problems when files move between machines.
• Match the language's rules. Java class files must match the public class name exactly, so BankAccount.java holds public class BankAccount.

Separate the things you write from the things the computer generates, and separate both from the data. That one rule gives a structure you can back up intelligently, because you only truly need to keep the parts you wrote — everything in the output folder can be rebuilt from them in seconds.

ics-projects/
├─ unit03-arrays/
│  ├─ src/            <- .java files you wrote
│  │  ├─ Sorter.java
│  │  └─ Stats.java
│  ├─ out/            <- .class files the compiler made (never back this up)
│  ├─ data/           <- input files the program reads
│  │  └─ scores.txt
│  ├─ docs/           <- planning notes, flowcharts, test plan
│  └─ README.txt      <- what it does and how to run it
└─ unit04-methods/
   └─ src/
      └─ Menu.java

A file that exists in one place does not really exist. Drives fail without warning, laptops get stolen, ransomware encrypts everything a user account can write to, and the most common disaster of all is a person deleting or overwriting the wrong file. The 3-2-1 rule is the standard professional answer, and it is worth following exactly because each number defends against a different failure.

1. Three copies of anything you care about — the working copy plus two backups. One backup can fail silently; two failing at the same time is far less likely.
2. Two different kinds of media — for example the internal SSD plus an external drive. If one type has a manufacturing flaw or a controller failure, the other is unaffected.
3. One copy offsite — cloud storage or a drive kept somewhere else entirely. A fire, flood or theft takes everything in one room, no matter how many drives are in it.

Copying a file before changing it is a real instinct and a reasonable one — you want to be able to go back. The problem is that manual copies scale terribly. After a week you have Sorter.java, Sorter_backup.java, Sorter_v2.java, Sorter_final.java and Sorter_final_v3.java, and nothing records which one compiled, what changed between them, or why. Sorting by date only tells you which was touched last, not which was good.

At a beginner level you do not need to master branching and merging. What you need is the habit: save a checkpoint whenever something works, write one honest sentence about what changed, and stop renaming files to record versions. Two commits named "reads the file and prints the average" and "fixed the off-by-one in the loop bound" are worth more than twenty files called final.

Compression finds redundancy and stores it once. Lossless compression (ZIP, PNG, FLAC) rebuilds the original byte for byte, which is essential for code and documents — a program with one bit wrong does not compile. Lossy compression (JPEG, MP3, H.264) permanently discards detail people are unlikely to notice, achieving far smaller files at the cost of never getting that detail back. Archiving a project folder into one ZIP also has a practical benefit that has nothing to do with size: it keeps the folder structure intact when a submission system would otherwise flatten it.

Programming means long stretches in one position, which is exactly the pattern that produces sore wrists, a stiff neck and tired eyes. None of these come from one bad session; they build up over months of small misalignments. Fixing the setup costs nothing and takes five minutes.

• Screen — top of the display at or just below eye level, about an arm's length away. A screen that is too low pulls your head forward, and your neck carries that weight all day.
• Chair and desk — elbows near a right angle with the forearms roughly parallel to the floor, shoulders relaxed, lower back supported. If your feet do not sit flat, use a footrest rather than dangling.
• Keyboard and mouse — directly in front of you, close enough that your upper arms hang naturally. Keep wrists straight and floating rather than resting bent on the desk edge while typing.
• Eyes — follow the 20-20-20 guideline: every 20 minutes look at something about 20 feet (6 m) away for 20 seconds, which lets the focusing muscles relax. Position the screen so windows and lights are to the side, never directly behind or in front of it.
• Movement — stand up and move every 30 to 45 minutes. The best posture is the next one; no single position is healthy for three straight hours.
• Cables and power — keep cables out of walkways, do not daisy-chain power bars, and keep drinks away from the keyboard. Most workstation damage is mechanical, not electronic.