Mike Torrettinni

You never noticed how end of comment line is cut off in italic? See example of characters at the end: d looks like o f looks like t

@Kas Ob. and @Lars Fosdal I see you both make sure strings stand out, why is that?

I agree. if It's a simple standalone method, I don't bother to create it's own enum, like for Enable/Disable Control. But when part of a feature, in it's own unit(s), then I can add a few enums without even blinking, of course most of them are of limited scope within a feature.

It would be really cool to be able to quickly change color scheme, using keyboard shortcuts: Subtle comments when you want to focus on code, and stand-out comments when you want to read the comments quickly:

Oh, that is the sample, ok got it.

What editor is this?

Oh, no, I never tried that so I have no clue how to do it, if possible.

Check option Show line breaks:

Oh, interesting. Right now testing orange comments on cream bg to be more subtle than the code, but still pop out:

Wanna share a combination you are using for a while? I just started testing different colors and not sure what will stick, right now testing different comments colors... not found the right one, yet.

True, that's why I opened this topic, to get some clarification, some sense of it.

I agree, but it's Nick Hodges... how are you not gonna follow his advice, even if it's a little out-there? 🙂

Thanks all for the feedback I already started making some naming changes! It was just interesting that Nick put this into a blog like it's some really bad practice, while is more about naming than anything else.

That looks like a sensible solution... I'm just thinking out loud: so many new enums need to be created. For example EnableControls, EnableMenus, EnableFeatures... they all accept boolean, and I do understand the purpose of using enums, but I have to define new enum type for every single True/false parameter.

I'm not sure I see the distinction between Nick's example and mine. What am I not seeing?

I ran Pascal Expert through some of the open source projects and no STWA8 (https://www.peganza.com/PEXHelp/index.html?stwa8_for_loop_with_possible_b.htm) , what your example triggers, was found in those sources. So, I assume this is quite rare to find in real code.

I have arrays that I export as csv file format, all mixed field types. I was trying to compare simple concatenation + vs MOVE to create lines to export, but MOVE is 30% slower than simple + in example below: Concatenating integer, boolean and char value require more operations (calculate length) than simple concatenating pure strings Is that the reason MOVE is just not as performant as simple + ? Or perhaps I use MOVE wrong in case of mixed types of fields? In example I have PrepareLineForExport that uses + for concatenation, and PrepareLineForExport_MOVE that uses MOVE, I was expecting MOVE to be faster: uses System.Diagnostics; type TData = record ID1: integer; S1: string; B1: boolean; S2: string; C1: char; S3: string; end; var xData: TArray<TData>; const cMaxLines = 10000000; cSeparator = ';'; procedure FillTestData; var i: Integer; begin xData := nil; SetLength(xData, cMaxLines); for i := Low(xData) to High(xData) do begin xData[i].ID1 := i; xData[i].S1 := 'Testing array data export'; xData[i].B1 := True; xData[i].S2 := 'String 2'; xData[i].C1 := 'A'; xData[i].S3 := 'String 3'; end; end; function PrepareLineForExport(const aDataIn: TData): string; begin Result := aDataIn.ID1.ToString + cSeparator + aDataIn.S1 + cSeparator + BoolToStr(aDataIn.B1) + cSeparator + aDataIn.S2 + cSeparator + aDataIn.C1 + cSeparator + aDataIn.S3; end; function PrepareLineForExport_MOVE(const aDataIn: TData): string; var vPos, vLen: integer; vStr: string; begin // Len = 5 x Separator + Len of Data SetLength(Result, 5 + Length(aDataIn.ID1.ToString) + Length(aDataIn.S1) + Length(BoolToStr(aDataIn.B1)) + Length(aDataIn.S2) + 1 + Length(aDataIn.S3)); vPos := 1; // ID1 vStr := aDataIn.ID1.ToString; vLen := Length(vStr); Move(vStr[1], Result[vPos], vLen * SizeOf(Char)); Inc(vPos, vLen); // Separator Result[vPos] := cSeparator; Inc(vPos, 1); // S1 vLen := Length(aDataIn.S1); Move(aDataIn.S1[1], Result[vPos], vLen * SizeOf(Char)); Inc(vPos, vLen); // Separator Result[vPos] := cSeparator; Inc(vPos, 1); // B1 vStr := BoolToStr(aDataIn.B1); vLen := Length(vStr); Move(vStr[1], Result[vPos], vLen * SizeOf(Char)); Inc(vPos, vLen); // Separator Result[vPos] := cSeparator; Inc(vPos, 1); // S2 vLen := Length(aDataIn.S2); Move(aDataIn.S2[1], Result[vPos], vLen * SizeOf(Char)); Inc(vPos, vLen); // Separator Result[vPos] := cSeparator; Inc(vPos, 1); // C1 Result[vPos] := aDataIn.C1; Inc(vPos, 1); // Separator Result[vPos] := cSeparator; Inc(vPos, 1); // S3 vLen := Length(aDataIn.S3); Move(aDataIn.S3[1], Result[vPos], vLen * SizeOf(Char)); end; // Make sure both methods create same data for export! procedure TestData; var i: Integer; begin for i := Low(xData) to High(xData) do begin if PrepareLineForExport(xData[i]) <> PrepareLineForExport_MOVE(xData[i]) then raise Exception.Create('Data build incorrect!'); end; end; procedure TForm2.Button1Click(Sender: TObject); var i: Integer; vLine, vLine2: string; vSW: TStopWatch; begin FillTestData; TestData; vSW := TStopwatch.StartNew; for i := Low(xData) to High(xData) do begin vLine := ''; vLine := PrepareLineForExport(xData[i]); end; memo1.Lines.Add('PrepareLineForExport: ' + vSW.ElapsedMilliseconds.ToString); vSW := TStopwatch.StartNew; for i := Low(xData) to High(xData) do begin vLine := ''; vLine := PrepareLineForExport_MOVE(xData[i]); end; memo1.Lines.Add('PrepareLineForExport_MOVE: ' + vSW.ElapsedMilliseconds.ToString); end;

Or we avoid each other threads, this would be nice. But is public forum, so no force.

just like: Fly Robin fly, right? 😉 I think we know how we contribute to each other topics.

With new 'knowledge', I tested what happens if I add values in consecutive expressions, like this: function PrepareLineForExport2(const aDataIn: TData): string; begin Result := aDataIn.ID1.ToString + cSeparator; Result := Result + aDataIn.S1 + cSeparator; Result := Result + BoolToStr(aDataIn.B1) + cSeparator; Result := Result + aDataIn.S2 + cSeparator; Result := Result + aDataIn.C1 + cSeparator; Result := Result + aDataIn.S3; end; OK, this is now slower: PrepareLineForExport: 1358 ms (single expression using + ) PrepareLineForExport2: 2242 ms I realize this is probably the most basic thing for most of you, for me this is something really new.

OK, this is something new to me! I never realized this in such a way. Thanks! Everyday something new 😉

OK, that I understand. I wanted to see if MOVE gives any benefit for my arrays, mixed field types. When I started I didn't realize how much code is needed vs +. Even though I use code-gen for the whole export/import process, it's a lot of code for arrays with 50+ fields. But it looks like + is already very performant, or good enough for now.

Is this not clear enough? I would really like to write clearer questions. What is missing here?

I think you are right, I would be happy with 10%+ performance gain, but of course 50% would be better for all the extra code needed, vs just +.

What do you think is missing from explanation in first post that would clear the confusion?