1. Old man’s talk
Delphi VS VC is already a very old topic, but I still want to talk about it here. It’s all my opinion. If you don’t agree, please laugh.
The benefits of RAD are easy to see. In terms of interface design, Delphi is actually better than VC. I want to write an unconventional transparent button. In Delphi, I only need to find a control, click the mouse, and modify the Caption. What about VC? It takes at least 10 lines of code to get it done. Of course, MFC's approach makes people understand the underlying principles of Windows, but the encapsulation of OOP is not well reflected. Developers need to understand all the underlying principles before they can write code. For me and most Being a beginner is a torture because there is no need to Yes, development deadlines are always tight and time is never enough. We cannot expect programmers to know all aspects of Windows programming. Some people know a lot about videos and some are good at networking, but no one is an all-rounder and is good at everything. is unrealistic, so encapsulation is very important. If I have to spend 30% or more of my time on a transparent button or a beautiful interface every time I develop a new product, then I will jump into the river:) Delphi is indeed better than MFC in terms of interface! Of course, it doesn't mean that MFC can't design beautiful interfaces, but it just takes too long and is not worth it.
Is RAD really all about benefits? Neither. At least not for beginners, because it makes people misunderstand that programming is just about moving the mouse and pulling the frame. The final result is that people think that Delphi is only used to write interfaces, and the bottom layer can't do anything. It seems that MFC programmers all talk about Delphi programmers: "In addition to having a beautiful interface, what else can your program do?" Wrong! In fact, apart from DDK, what can't be developed in Delphi? Which API header file does Delphi not have? Borland has not converted, but JEDI has converted it. Even if JEDI has not converted, it is the same if you do it yourself. As long as you give me the C header file, I can convert it. The short conversion instructions on JEDI should be a must for every Delphi programmer. required documentation. Once the header files are converted, all that’s left is to start writing. What MFC can do, Delphi can do too! video? network? directx? Audio? What can't Delphi do?
2. Sub-process
When writing an event, many people just start writing it. No matter how long the code is or how many things are done, as long as it is done in an event, they just write it down in their head. The result is that they have no way to start when they revise it a few months later. , because the code snippet is too long. So why not break the code snippets apart? Human attention is limited, and you will feel dizzy if you read more than 100 lines of code in one go. Delphi seniors told me one thing: all processes (the process here includes PROcedure and function) should not exceed 25 lines! Because this length of code won't make your head spin, you'll easily understand what the process is doing.
So how do you take apart the things that were originally done in an event? There are many methods, my experience is modular. For example, if there are many different things to do in an event, then the different things are converted into different sub-processes, and then called in the main process. Most of the main processes are some judgments and loops, and there will be no specific implementation process. This will create a lot of code snippets, but it will keep your focus!
Principle: A process only does one thing, and does it well.
Reference: VCL source code. Looking at the VCL source code, there are rarely more than 25 lines of code!
3. Parameter name
I remember when I first learned the SDK, I felt dizzy when I saw the Hungarian notation, it was too much! I can’t remember it! So I hate that inventor :) Finally Delphi appears and the days of dancing in shackles are over! In Delphi, defining a string with a variable name like strDoSometing is ridiculous and unnecessary. As long as your procedure is short and no global variables appear, you don't need such a prefix. for example:
procedure SubPro;
var
i : byte;
Width, Height : integer;
begin
Width := GetWidth;
Height := GetHeight;
for i:=0 to 9 do
begin
DrawThread := TDrawThread.Create;
DrawThread.Width := Width;
DrawThread.Height := Height;
DrawThread.Start;
end;
end;
I think that even though such a code segment has no comments, it is easy to know what it is going to do. So, please remove all prefixes and underscores, Delphi programs do not need these! Our parameter names only need verb + noun. We only need to explain the function of this parameter. We don’t want redundant things. Simplicity is beautiful. The advantage of Pascal is that the code seems to be talking, rather than reading from heaven. In your head, What you think is what the code looks like. Elegant and simple, these are the benefits of Pascal, please abide by it!
Principle: Simplicity is beautiful!
4. Sub-window
Many people directly operate the controls in the sub-window when calling a sub-window, such as:
if SetAlarmParamDlg.ShowModal = MrOK then
begin
AlarmTimes := StrToInt(SetAlarmParamDlg.Edit1.Text);
AlarmArea := SetAlarmParamDlg.SpinEdit1.Value;
end;
Oh my god, if tomorrow users think the Edit or SpinEdit you use looks ugly and replace it with a beautiful control, what will you do? Not only do you need to modify the code of the sub-window, but you also need to modify the code of the main form. Of course, a program with one or two sub-windows will not cause you pain. What if it is a program with more than twenty sub-windows? It took a day, but the reason was just to change a control! Why not try another method? If you use attributes to represent the parameters you want to use, you will save countless codes.
//main form
if SetAlarmParamDlg.ShowModal = MrOK then
begin
AlarmTimes := SetAlarmParamDlg.AlarmTimes;
AlarmArea := SetAlarmParamDlg.AlarmArea;
end;
// subform
interface
private
FAlarmTimes : integer;
FAlarmArea : integer;
published
property AlarmTimes : integer read FAlarmTimes write FAlarmTimes;
property AlarmArea : integer read FAlarmArea write FAlarmArea;
implementation
...
FAlarmTimes := StrToInt(Edit1.Text);
FAlarmArea := SpinEdit1.Value;
ModalResult := MrOK;
...
As long as you persist in this way, you will find great benefits. A sub-window only does its own thing, and the interaction between the main window and it is done through attributes. As long as the interface remains unchanged, modifications to the sub-window will not affect the main window. No matter how the appearance of the sub-window changes, how the controls are replaced, or how the code is modified, the entire program remains the same, only the interface has changed.
Principle: Modularize your sub-windows. Windows are also classes. How to communicate between classes should be how windows should communicate.