PureBasic Forums - English

Posted: **Wed Oct 21, 2009 9:37 pm**

C/CPP coders still know about how helpfull it is, to create an array and fill it directly with datas!
The same helpfull thing for getting more readable sources with less mistakes (bugs) and cleaner codingstyle, is to write things not in just only one codeline... still miss the possibility to write stuff in mulilines!

Code: Select all

Wish to fill arrays directly with datas like following idea... (ofcourse multilines would be nice as it is my 2nd wish ^^)

Dim Map( 10, 10 ) = {
  1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
  1, 0, 0, 0, 0, 0, 0, 0, 0, 1,
  1, 0, 0, 0, 0, 0, 0, 0, 0, 1,
  1, 0, 0, 0, 0, 0, 0, 0, 0, 1,
  1, 0, 0, 0, 0, 0, 0, 0, 0, 1,
  1, 0, 0, 0, 0, 0, 0, 0, 0, 1,
  1, 0, 0, 0, 0, 0, 0, 0, 0, 1,
  1, 0, 0, 0, 0, 0, 0, 0, 0, 1,
  1, 0, 0, 0, 0, 0, 0, 0, 0, 1,
  1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
}

Code: Select all

Wish to write code in multilines... more readable source == less erros/mistakes

HWND CreateWindow(      
    LPCTSTR lpClassName,
    LPCTSTR lpWindowName,
    DWORD dwStyle,
    int x,
    int y,
    int nWidth,
    int nHeight,
    HWND hWndParent,
    HMENU hMenu,
    HINSTANCE hInstance,
    LPVOID lpParam
);

best regards

Posted: **Wed Oct 21, 2009 10:32 pm**

The trouble with multiline source with basic is that you need either a line delimeter such as a ';' which isn't basic, or a really weird line continuation character such as '_' which is ugly.

'Choose and perish, Choose! Choose the form of the Destructor!'

Posted: **Thu Oct 22, 2009 12:28 am**

inline asm isnt basic too - so we have/should remove this feature from PB? ^^
I think even a modern language should support features like this and make coding easier and more readable

Posted: **Thu Oct 22, 2009 4:38 am**

+1 what language doesn't allow this? This is so helpful for filling two dimensional arrays with initial data.

Posted: **Thu Oct 22, 2009 5:17 am**

I would rather see a way to redirect the pointer of an Array correctly and conveniantly to a DataSection.

Posted: **Thu Oct 22, 2009 6:30 am**

Multiline sources have been requested here a million times. Even va!n has been here long enough to know that.

Posted: **Thu Oct 22, 2009 6:36 am**

PB wrote:Multiline sources have been requested here a million times.

Very true. - Could it be, that people really do want that feature?

(In fact, even I would be delighted with that.

)

Posted: **Thu Oct 22, 2009 1:53 pm**

Kale wrote: The trouble with multiline source with basic is that you need either a line delimeter such as a ';' which isn't basic, or a really weird line continuation character such as '_' which is ugly.

Why is that ugly? It's how you present it!

In CodeCaddy I implemented multi line continuation characters, and it works well. Yes, the _ at the END of a line may not be such a nice solution, but it works great AT THE START of a line.

Code: Select all

If a = 1 OR
    _ b = 1 OR
    _ c = 1
  ....
  ....
Endif

CodeCaddy does both, but I tell you I'd love to have multiline support with underscores, it makes very complex conditions with long variable names a breeze!

Posted: **Thu Oct 22, 2009 6:32 pm**

va!n wrote:inline asm isnt basic too - so we have/should remove this feature from PB? ^^

Lol, you know full well that is implemented because of the underlying assembler, you would be an fool to not include the ability of passing assembly directly if you are ultimately compiling using an assembler.

'_' looks horrid btw. It doesn't matter where you put it.

Code: Select all

If a = 1 OR
    _ b = 1 OR
    _ c = 1
  ....
  ....
Endif

yuk!

Code: Select all

If a = 1 OR _
    b = 1 OR _
    c = 1
  ....
  ....
Endif

yuk!

surely these things can be handled via a pre-processor and then people can choose their own character? IMHO line continuation characters are always abused and obfusticate code. Each to his own i guess but i like pretty code, even when reading forums!

And you are right this has been asked for many times (by the same people over and over) but that doesn't mean it should be added, like OOP.

Posted: **Thu Oct 22, 2009 7:07 pm**

Code: Select all

Dim Map( 10, 10 ) = myDatas

arraySection(myDatas)
    1,0,1,0,2,2,3,4,0,0,
    2,5,1,3,2,4,6,3,4,5,
    1,1,1,1,1,1,1,1,1,1
endarraySection

Just a vision i got when i saw this topic. =)

Posted: **Thu Oct 22, 2009 7:21 pm**

I do agree, that line continuation characters are (a little) ugly,
but I do not see them as ugly as extremely long lines you have to scroll
long ways to see all of them - one part at a time only, that is!

As multiple lines are wanted for viewing procedures, that probably
do have multiple parameters, it would be a nice approach imo,
to let the procedure continue in the next line,
when it it obvious that it is not done.

This might be expressed as:

"," is used to separate the parameters of a procedure
and additionally as line cotinuation charater,
if it occurs at the end of a line.

just as was shown by va!n and now by Ampli above

Does anyone see a need for any other kind of "line continuation"?

Edit:

Anything up to the closing bracket ")" belongs to the same "logical line"

would be a more liberal and therefore imho better approach.

Edit: Even more flexible and maybe easier to implement could be

marking an area, where line breaks are removed before final compilation

Like:

Code: Select all

{
  x.i
  =
    NiceProcedure
    (
     area,
     where,
     "line breaks",
     are,
     "removed before compilation"
     )
}

Posted: **Thu Oct 22, 2009 7:37 pm**

Marlin wrote:...
but I do not see them as ugly as extremely long lines you have to scroll
long ways to see all of them - one part at a time only, that is!

I'm programming for over 25 years now and I always managed to avoid snakelines...
not to mention that lines broken apart are not really better to read... they just look messed up.

only argument is filling an array.
Some ArraySection where the Array's pointer could automatically be reset to would be a sound idea.
should not be the big problem to substitute the 4 more bytes in the beginning and to prevent re-Dim-ing of such arrays.

Posted: **Thu Oct 22, 2009 8:20 pm**

Kaeru Gaman wrote: not to mention that lines broken apart are not really better to read... they just look messed up.

I beg to disagree

Splitting an expression over multiple lines can make code actually more readable. Here are some examples from real code:

Code: Select all

...
format_smart = ReadPreferenceLong("format_smart",#True)
format_multiline = ReadPreferenceLong("format_multiline",#True)
format_multiline_indent = ReadPreferenceLong("format_multiline_indent",2)
format_indent = ReadPreferenceLong("format_indent",2)keywords_up = ReadPreferenceString("keywords_up", _
  "If|ElseIf|Else|While|Repeat|Case|For|ForEach|With|CompilerIf|" + _
  "CompilerElse|CompilerElseIf|Structure|Procedure|Procedure.?|" + _
  "Enumeration|DataSection|StructureUnion|Default|PanelGadget(*|" + _
  "Select|StartDrawing(*|Macro")
keywords_down = ReadPreferenceString("keywords_down", _
  "ElseIf|Else|EndIf|Wend|Until|Case|Next|EndWith|CompilerElseIf|" + _
  "CompilerElse|CompilerEndIf|EndStructure|EndProcedure|EndEnumeration|" + _
  "EndDataSection|EndStructureUnion|Default|CloseGadgetList(*|EndSelect|" + _
  "StopDrawing(*|ForEver|EndMacro")
...

It also allows you to spread conditions over multiple lines, which especially comes in handy when dealing with multiple different conditions, for example something has to be executed if (a and b) or (c and d), as each complex condition could be on its own line, it's then easier to understand the meaning of a set of conditions, as it's clear what belongs to what.

Code: Select all

...
SelectElement(x_dir_file(),n)
If ( save_excludesnapshots And x_matchpattern(x_dir_file(),"*.pb.*.snapshot*.bak",#x_parse_anycase) ) Or _
    ( save_excludebuilds And x_matchpattern(x_dir_file(),"*.pb.*.build*.bak",#x_parse_anycase) )
Else
  RenameFile(path+x_dir_file(),path+name+"."+x_strex(save_nr,save_mask)+".wrap.bak")
  save_nr = save_nr+1
EndIf
...

Code: Select all

...
If old_filter_type <> filter_type
  _ Or old_search_firstnr <> search_firstnr
  _ Or old_search_extra <> search_extra
  _ Or hit_n < old_n
...

But hey, if people want me to add a different syntax to CodeCaddy I can do that

Posted: **Thu Oct 22, 2009 8:28 pm**

Kaeru Gaman wrote:I'm programming for over 25 years now and I always managed to avoid snakelines...

I would like to be able to avoid "snakelines" without any need of change in code logic,
extra instructions or such, I would not otherwise have undertaken!
(Defining "snakelines" as "too long lines that might even need horizontal scrolling" in this case)

Why should we need to scroll just to look at optimized code

(I should probably call it "non disoptimized code".)

In any case, I do not see, why such a feature should be of any disadvantage to anyone.

You still would be able to code the way you want,
even use very long physical lines if you choose to.

Why not allow others to make their own choice?

Kaeru Gaman wrote:lines broken apart are not really better to read... they just look messed up

I disagree on that.
At the very least, I can see them completely and do not need to scroll to find out...

I'm not talking about intentionally messed up lines or such,
or lines that do not fit on the sceen anyways.

In the later case I still would consider it an improvement in readability
if horizontal scrolling can be avoided!

Posted: **Thu Oct 22, 2009 8:43 pm**

depends on what you call an "instruction"...
using a variable dummy with a decriptive name does not really count as "extra instruction" in my eyes.
and first setting up the parameters with descriptive names and then making the Call is way more readable to me than a split line without any hint what is what.

the first example of blueznl looks.. terribly ugly.
best argument for putting the parameters in string variables first.

PureBasic Forums - English

Arrays and Multilines

Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines

Re: Arrays and Multilines