Introduction
Hello. This is TORII, an old programmer at Colorkrew (hereinafter referred to as CK).
Well, today I would like to talk about the past and present related to programming from me, who is one of the top three (I don't know exactly) of the Colorkrew Programming Senior Citizens' Association.
In fact, I am still a good place for young people in the world's programming senior citizens' associations, but recently, while the number of young, fresh, and pitched engineers in our company has increased one after another, the elderly have lost their minds, and before I knew it, it was like that. If I just sat down, it would have happened. There are some really strange things.
Let's get started.
Episode 1 Engineers and Programmers
Since the beginning of mankind, there have been many people who are called system engineers who handle upstream processes, but in the past 10 years or so, the number of people who call themselves engineers who make a living by writing programs has increased considerably.
No, it may have been like that for a long time, but to be honest, I don't really know when it started to multiply. As a subjective impression, it is an impression that has suddenly increased. It's already a wall.
What is the difference between an engineer and a programmer?
I think I started calling myself an engineer in the early 2010s, but before that, I thought of myself as a programmer.
The reason for the change was that when I wrote my position on my business card, I was told to write "producer" according to the company's rules, and as a result of protesting and adjusting, I protested and adjusted, and when I decided to make a decision after consulting with my superior, I initially said that I wanted to be a "programmer", but for some reason it was rejected, so I reluctantly wrote "software engineer". In general, it seems that a programmer is a person who only codes and modifies based on a design document made by someone. Or people who don't manage.
There seems to be a popular theory that engineers are people with engineering degrees, and in fact, it seems that there are countries overseas where it is difficult to get a job in the IT field without a degree. Of course, such a degree is not required in Japan. Even elementary school students can call themselves engineers.
It really changes depending on the industry, situation, and context, and there are many IT occupations that do not write programs now, and they are also called engineers, so for those who write programs, it is basically a matter of mood (it sounds more amazing to say engineer than programmer), and it seems good to think of it as a general term that includes various IT occupations.
That's why I now call myself an engineer. But at heart, he is an eternal programmer.
Episode 2 Tabs, Spaces, and Brackets
This is a question of whether to use tabs or spaces for indentation in source code. I used to have the impression that there were many tabs, but now most of the space is used. It was settled without knowing it. No, I'm surprised.
I know the problem with tabs is that the layout breaks down when used for purposes other than structuring.
But space is space, and it's troublesome to press space/backspace N times to write, and if you make a mistake in the number of times, the indentation will shift. The cursor may be misaligned when copying and pasting.
Huh? Would you just press the tab key? That's the power of the editor (soft tab).
If you use a good programming editor, you will almost never have any problems. In the case of a normal programming editor, if you inadvertently copy from the middle of a space, you may end up with an indentation line that is one character too much or too small. If it's one letter off, you won't notice it.
The worst thing is that you can only use a cheap editor that does not have a soft tab itself, and you have to hit the space N times repeatedly, so it becomes so painful that you want to curse, "What is the person who instructed me to use the space indented?"
Well, such an environment is rare now, so there is no problem with space at all, yes.
Several times a year, there are times when it becomes an indentation with a partial excess or deficiency of one character, but I fix it when I see it and don't really care about its existence (oh, if you see it, please make a pull request).
In a similar story, there is also a story about where to start the parentheses of control statements such as if and for. It is written at the end of the same line as the control or on the next line.
Nowadays, except for some languages such as C#, it seems that writing on the same line as the control sentence is mainstream.
When I started writing programs, I wrote on the same line as the control statement, but in the project I did at the very beginning, there were frequent errors that made the start and end of parentheses not match each other. With this way of writing, you can't tell at first glance where the parentheses are insufficient, excessive, or indented.
Well, I'm talking about not writing control statements that seem to be far apart, but it's the height of youth.
The number of labels in the switch sentence was 1000 or so, but it was so stupid that it exceeded that and a mysterious glitch occurred.
So I changed the style to write the beginning of parentheses on the next line. Then, as soon as I got there, such stupid errors stopped happening. This is because if there is no parenthesis start in the next line, it will not be indented, so you can tell where the abnormality is just by looking at it. It's the best.
Since then, I have been writing that way when I write individually.
But it seems that the world today does not write in such the best way. I think the main factor is probably that we cannot allow one line to be consumed just by the starting line of parentheses, but it is becoming difficult for us to be unable to respond to parentheses (due to the power of the editor, etc.).
Well, no matter how you write about tab space or parentheses, the editor will automatically correct it according to the format set by the project the moment you save it, so it's a good time to write in any style as long as you want to write.
Episode 3 License Notation
When I was still a rookie in the new recruit training, I was taught to write the license notation of the company name at the beginning of the source code during the new employee training.
Under Japanese copyright law, you don't have to write it, but I was aware that I should write it in addition because I was going to post a description of the file anyway.
However, in this web industry, or rather Colorkrew, I have never seen a license notation written in the source code we write, although there is a solid license notation in the open source source code. I haven't seen a header that explains the contents of a file. (*1)
There seems to be no custom to describe it. At first, I was puzzled, but recently I've started to think that I don't have to write about it.
Even if you don't write it, copyright is established, and if the source code is leaked...... I thought.
But these days, I think it's better to properly attach the source code of your company's products.
Finally
I've been writing a lot of bad sentences, but if it's popular, it may continue. Member of our Colorkrew programming senior citizens' association...... We are recruiting employees at any time.
If you are interested, please contact us below.
https://recruit.colorkrew.com/
*1) Is the exception a file created by Xcode? It will automatically create a file name and copyright.
That's why sometimes you see Xcode-generated source code with a personal name as Copyright instead of a company name.
Since the Xcode project file is set up like this, if you create source code via Xcode, it will be copyrighted by that person no matter who makes it......