VAR as a topic

Forum for discussion about the documentation project.
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

VAR as a topic

Post by speedfixer »

Perhaps a doc could be written that would show when VAR **should** ever be used in a program?

It has its place:
Simplicity in a small program.
Arbitrary variable assignment in more complex programs.


Also, could we **never, ever** use VAR in some other keyword example? It adds unnecessary uncertainty and confusion for a beginner.


david
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: VAR as a topic

Post by coderJeff »

speedfixer wrote:when VAR **should** ever be used in a program?
I think the trade-off with VAR versus DIM is strict typing for convenience. If explicit and strict typing is your thing, then probably never.
I like your approach; just because it can be used doesn't mean it should be, but it has its uses.

Maybe for a kind of best practice if VAR is used, then it's implied type should be obvious - or at least local so don't have to look too far to figure out its type.

VAR has some symmetry with CONST:
In either case, if the symbol is going to be used globally, a better choice of name would help make it obvious what kind of value it should hold.

Code: Select all

const i = 196883ull
const s = "hello"
var vi = 196883ull
var vs = "hello"
In some cases (like in #macro or template-like code) the actual type is unimportant and the purpose is well explained by the steps:

Code: Select all

scope
	'' swap a and b
	var tmp = a
	b = a
	a = tmp
end scope
In the compiler source code, VAR is used on many places where the actual name of the type returned from a function doesn't really matter because the variable is compared with other well named constants or passed to other well named functions.
Some made up thingy:

Code: Select all

Sub FrobnicateGizmos( byref g1 as string, byref g2 as string )
	var a = getGizmo( g1 )
	var b = getGizmo( g2 )
	prepareGizmo( a )
	prepareGizmo( b )
	Frobnicate( a, b )
End Sub
For a real example from fbc see rtl-string.bas:rtlStrSwap()

For me, if VAR is used, then there must be well named initializers and variables to go along with it.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: VAR as a topic

Post by fxm »

Me who likes strongly typed languages, I rarely use the keyword 'VAR' except where precisely the variables passed are not typed (and can thus be of different types according to the call) as for example inside the body (or for processing the result) of some macros.
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: VAR as a topic

Post by speedfixer »

So it seems we each prefer more strongly typed variables.

Then, for the sake of simplicity and clarity:

anyone, everyone: if you review any example in the docs could we please remove all VAR uses except in the VAR keyword page and a select few others?

david
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: VAR as a topic

Post by fxm »

Except the 'VAR' documentation page, there are 10 other documentation pages using the 'VAR' keyword in their 'Example' paragraph: In my opinion, this is not at all justified for only the last 4 cases.
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: VAR as a topic

Post by dodicat »

var can be very valuable (like auto in C++)

Code: Select all

#macro engine
 var i=begin,j=finish
 var x =array(((I+J)\2))
 While I <= J
 While array(I) < X :I+=1:Wend
 While array(J) > X :J-=1:Wend
 If I<=J Then Swap array(I),array(J): I+=1:J-=1
 Wend
 If J >begin Then quicksort(array(),begin,J)
 If I <Finish Then quicksort(array(),I,Finish)
#endmacro

Sub quicksort overload(array() As double,begin As Long,Finish As long)
    engine
end sub

Sub quicksort(array() As string,begin As Long,Finish As long)
    engine
end sub

dim as double d(...)={3,7.4,-6,0}

dim as string s(...)={"good","bad","ugly","Clint"}
quicksort(d(),lbound(d),ubound(d))
quicksort(s(),lbound(s),ubound(s))

for n as long=lbound(d)to ubound(d)
    print d(n),s(n)
next
sleep

  
I always use it if I can.
Code is just as easy to read, speed unchanged.
It is a personal choice for coders after all.
Why obliterate it?
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: VAR as a topic

Post by MrSwiss »

No one ever said, that this is for Beginners (a weak argument anyhow).

VAR can easily be forced to be of a wanted datatype (by those that know "the basics of datatypes").
There are in fact three prerequisites to success:
  • 1) knowledge of all Standard Datatypes (of FreeBASIC)
    2) coercion & conversion
    3) literal sufixes
Thereafter, it's as simple to use, as Dim As datatype identifier.

Code: Select all

Var s = "", cnt = 0ull, x = 0u, y = 0
where:
s = String, cnt = ULongInt, x = UInteger, y = Integer (signed) ...
srvaldez
Posts: 3373
Joined: Sep 25, 2005 21:54

Re: VAR as a topic

Post by srvaldez »

I know VAR can be convenient but I hate it's use, I like to know the type a variable has by looking at the definition and VAR can seriously obfuscate the code in my opinion.
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: VAR as a topic

Post by TJF »

dodicat wrote:I always use it if I can.
Code is just as easy to read, speed unchanged.
It is a personal choice for coders after all.
Why obliterate it?
I second that. I also use VAR whenever possible. It doesn't only help when declaring local variables in a short and readable form like

Code: Select all

VAR a = "", b = 1uL, c = .5
The real advantage is when you deal with big libraries and pointer types. You need not take care of each character in the type name, just let the compiler do the work. I hate to use DIM to create a structure for a return value. When I'm realy unsure about a type, a simple

Code: Select all

#PRINT TYPEOF(b)
will make it clean.

Instead of removing that keyword from example code, I'd encourage beginners to use it.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: VAR as a topic

Post by fxm »

TJF wrote:The real advantage is when you deal with big libraries and pointer types. You need not take care of each character in the type name, just let the compiler do the work. I hate to use DIM to create a structure for a return value.
This is why in the list of 10 pages that I provided above, the example of the Cairo page is one of the pages where the use of 'VAR' is justified:

Code: Select all

Var surface = cairo_image_surface_create_for_data(ScreenPtr(), CAIRO_FORMAT_ARGB32, SCREEN_W, SCREEN_H, SCREEN_W * SizeOf(ULong))

Var c = cairo_create(surface)
srvaldez
Posts: 3373
Joined: Sep 25, 2005 21:54

Re: VAR as a topic

Post by srvaldez »

I agree with fxm, I wouldn't mind VAR at all if there were an IDE that would show the type on mouse-over, having to #PRINT TYPEOF(b) is a pain
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: VAR as a topic

Post by speedfixer »

In truth, I thought I saw more than these few.

I'm not suggesting that VAR does not have value, or that it should be warned away from as bad practice. Everyone has their own style.

VAR in ProPgProperties at least will be contained and not cause problems outside of the function it is used in. But, no clue why it is used and departs from declarations used in the code presented above.

VAR in KeyPgString just doesn't make sense. Why show a keyword then show how to avoid using it?
Without further explanation, the most direct conclusion would be that VAR is a synonym for STRING.
Silly conclusion for us, but maybe not for a complete noob. It should either be changed, or this new keyword needs to be added to the links below.

VAR in KeyPgOpStep implies that any automatic type assignment will have no bearing on operation results. That just isn't true.

VAR in KeyPgThreadDetach suggests again that the resulting type is not important. Immediate use here works, but if you have thread management routines that need stored thread pointers, that can lead to some very bad code across different platforms. Consistency would suggest that the other thread functions should use VAR also.

re: TJF: "The real advantage is when you deal with big libraries and pointer types."
I feel just the opposite. Much more important to remove any ambiguity in larger code sets. In order to use that function in Cairo in some other manner, a lot of research into the Cairo lib needs to happen. Just my opinion.


Nice to see these other opinions on its use.
This isn't that critical. I just think it should ALWAYS be as clear and simple as possible for any beginner using the docs.

david
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: VAR as a topic

Post by fxm »

'VAR' is a bit restrictive to define a variable (in addition to: 'WSTRING' is not supported with 'VAR')

Var [Shared] variablename = expression
is equivalent to:
Dim [Shared] As TypeOf((expression)) = expression
which implies that 'VAR' cannot replace 'STATIC', which means that a static variable in a compound instruction block or in a procedure scope cannot be defined with 'VAR'.


[edit]
See the following post from dodicat.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: VAR as a topic

Post by fxm »

@speedfixer,

This is also why I proposed to replace 'VAR' by 'DIM' for these 4 cases: As for Cairo, I think the 2 types (for 'VAR') are respectively:
  • cairo_surface_t ptr
    cairo_t ptr
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: VAR as a topic

Post by dodicat »

You can use var for a static variable.

Code: Select all

function f()byref  as zstring ptr
     static var g=strptr("  Hello")
      return g
end function


print *f

for n as long=1 to 10
    var x=str(n)
f()=strptr(x)
print *f
next

var byref z=f
z=strptr("  Goodbye, press any key to end . . .")
print *f
sleep



 
I have used this in cairo
Var surface = cairo_image_surface_create_for_data(Screenptr(), CAIRO_FORMAT_ARGB32,xres,yres,xres*4)
Which was quite handy at the time.
Also, likewise, var is quite handy in some winapi code where the compiler works out what exactly it is, you can always of course find out what it is yourself and use dim instead.
Post Reply