What is best... define.s variable or define variable.s

[Oso]

Menu > Tools > Structure Viewer > Tab 'Structures' > scroll down list to 'String' and doubleclick to see Definition

Thanks, is that the below, or something other?
https://imgur.com/a/GOhrA5D

[#NULL]

Yes, that's the one.

[Little John]

Yes, $ is convenient and it makes it clear throughout the code. But I was thinking more in terms of the range of variable types, not only strings. For example, the PB documentation lists a dozen Basic Types, some of which include the below.

Code: Select all

.b byte
.c character
.u unicode
.l long
.i integer
.d double

Let's assume we've defined our variables at the top of our code. When someone else happens to be maintaining the main body of our code, it isn't always going to be clear what the types are, just from looking at variable names alone. It's necessary to keep referring back to the definitions, in other words.

Therefore, would it be reasonable to append all variables with their type, throughout the code? Or would that be regarded as unnecessary 'bloat' by many PB developers? It's often better to follow the developer community norms.

I think most of the variable types are only needed in structures, for instance for reading a specific file format, or when an API function requires particular data types. For normal variables, I personally almost exclusively use .i, .q., .d and $.
When a variable e.g. holds values in the range from 10 to 100 during the course of a program, some people use .b as type, because that is big enough for this variable. However, the native data type for the processor is .i (.i denotes a 32-bit variable in an x86 program, and a 64-bit variable in an x64 program), so that it's normally better to use this type – except when you have a huge array, list or map with that variable.

Anyway, I think on principle it would be reasonable to append all variables with their type, throughout the code. But I can't recall ever having seen code like that here on the forum. For me personally, it's important anyway to split the code into logical blocks (aka procedures), which are as independent from each other as possible, and which are not too big. And in small procedures, the definition of a variable is never far away from any point where it is used.

Some people here on the forum are using something similar to Hungarian notation. Personally, I don't like that. If I would like to read the type of a variable every time it occurrs in the code, I actually would use what PureBasic offers: .i, .d etc. When I'm prepending a variable with a certain character, then it is not for showing its type, but its scope. So I use this:

Code: Select all

Global g_GlobalVar$
Define s_SharedVar.i

(and no prefix for variables that are neither Global nor Shared).

[chikega]

Not that this will make a big difference in ones code, but it's something I found by accident while playing with PB string types. It is not documented, but:

Code: Select all

Define$

appears to function the same as

Code: Select all

Define.s 

[Oso]

Not that this will make a big difference in ones code, but it's something I found by accident while playing with PB string types. It is not documented, but:

Code: Select all

Define$

appears to function the same as

Code: Select all

Define.s 

Thanks for posting this, I'm beginning to get the impression with PB that there are one or two hidden concepts that aren't always documented. I think it emphasises the importance of sharing ideas on this great forum here!

[Olli]

I can suggest you this :

Code: Select all

Structure main

 a.i
 b.i
 c.i
 
 name.s
 
EndStructure


Procedure displayC(*this.main)
 With *this
 
  Debug Str(\c)
 
 EndWith
EndProcedure




Procedure main()
 With *this
 
  Define *this.main = AllocateMemory(SizeOf(main) )
  
  \name = "Friday "
   \a = 5
   \b = 3
   \c = \a + \b
   displayC(*this)
 
 EndWith
EndProcedure



main()

There are lots of convenient in writing through this syntax. Define is, here, not used a lot, and is replaced by a personnal structure. This is compatible with several suggests in this subject. Knowing :
- try to use one Define directive per variable
- not to blend several types on the same line.
- try to keep the type on the end of the source line : this allows you to migrate easily variables definings to structure defining.