You can measure the code in different ways. Here is an overview of how it can be measured and how it is handled for this size coding challenge, the Vintage Computing Christmas Challenge. Read this carefully, if you want to optimize "your bytes".
In general, we differentiate between the size of source code, files and used memory.
Size of the complete source file. To make the source file shorter, you might consider removing comments. For a nice documentation, you might consider supplying two files: one with and one without comments.
Examples for source code files are .c, .java, .js, .bas and so on. Usually you can just take the size of the source code file. The file might as many bytes as you had been typing characters on the keyboard.
Be aware that BASIC can be saved in binary/tokenized ("executable file") and ASCII (source file) form.
Size of compiled code, e.g., runnable files. Such files often include not only the necessary code for the main task (which is the implementation of the algorithm), but also metadata to place the code correctly, measure its size, save its filename and type, attributes, checksums, etc. The file size is absolutely platform dependent. Some platforms even don’t use bytes but blocks for measuring the size. Some platforms might benefit from an efficient file format, others might not. Many file formats also only exist on PCs, while they don’t exist the same way on the native machine.
Example for executable files are .exe (PC), .com (PC), .xex (Atari), .prg (Commodore), .bin (several platforms), etc. While it's easy to determine this size, it might be worth to look further into the format, as these files often contain metadata.
Definition: The code which was implemented in order to fulfil the required task. This may include an algorithm plus self-defined data used within the algorithm. It does not include metadata like the filename, type, size, location, start address, checksums, etc. of the code. Used routines and libraries from the environment (machine and language) aren’t counted as well.
As stated above, compiled files mostly contain extra data to describe the file or in order to start the real program easier. These additional bytes do not provide any functionality directly connected to the main task. Therefore, they do not need to be counted.
Compressed files are not allowed in this challenge. The Tic-80 for example supports compressed files. In such a case, you shall use the uncompressed file or the source code for measurement.
The first two bytes describe the start address. They need not be counted (for assembler and BASIC as well).
For assembler programs, the BASIC stub (e.g. 10 SYS2061) can be subtracted as well. In this case, the code of course my not refer to any data within this stub or to any data (e.g. zero-page values) that have been influenced by the stub.
The header of bin files usually has 128 bytes with some information like memory location, start address, file size, name, etc. If you don't access the header's data you can subtract all 128 bytes.
This file format doesn’t contain any bytes except of the actual code itself. To run this file, you need to load it to the right location and start it.
This file format can contain several parts. Even a loader for the main code might be included. Therefore, the file size can’t directly be compared to most other file formats. This file format is often provided for convenience.
A very minimalistic file format that doesn’t contain any additional bytes for headers and such. It’s always loaded at 0100h and can therefore be loaded and started directly without a separate loader program.
You want to build something somewhere. First, you select the country (the platform). Then you chose the material (the language). After that, you select a specific lot (memory space). Now you start your building process. It doesn’t matter which country (platform), material (language) and lot (memory space) you chose. Only the used building space is counted. If the country (platform) provides you some nice means (libraries) this doesn’t matter as well. Also, paper work (file metadata) doesn’t matter if it is not used for the build process.