Templates

Monkey Forums/Monkey Programming/Templates

ziggy(Posted 2014) [#1]
What do you think of this template for a command line tool done in Monkey?
Import commandlineapp

'summary: This is the command line tool starting point:
Function Main()	
	Local tool:= New CommandLineTool()
End

'summary: This class handles the launching and parameters of the command line tool
Class CommandLineTool Extends CommandLineApp

	'summary: This is called when the command line tool launches.
	Method New()
	
		#REM
		Notice there are several field defined in this class, such as assemblyLocation, assemblyName and  parameters.
			- Self.assemblyName contains the name of the tool executable file (IE. the EXE file in windows os)
			- Self.assemblyLocation contains the path in the filesystem where the tool is located.
			- Self.paramters is a string array with any parameter passed to the tool. If no parameter is present, this array is of length zero.
		#END
		
		'Place the command line tool code here:
		
	End

End


The priject, will also contain a pre-made CommandLineApp class with this code:
Import brl.filepath
Import os

'summary: This class handles the launching and parameters of the command line tool
Class CommandLineApp Abstract

	'summary: This field contains the name of this tool assembly. That is, in windows, the EXE file of this tool.
	Field assemblyName:String

	'summary: This field contains the location in the file system where this tool is stored.
	Field assemblyLocation:String

	'summary: This array of strings contains all the paramters passed to this command line tool from the terminal or console.<br>If none is passed, this array will be of length zero.
	Field parameters:String[]

	Method New()
	
		'this is the tool executable name (on windows, the EXE file name):
		assemblyName = filepath.StripDir(os.AppArgs[0])
	
		'This is the tool executable path, the folder where the assembly is located:
		assemblyLocation = filepath.ExtractDir(os.AppArgs[0])
		
		'We get the list of parameters
		parameters = os.AppArgs[1 ..]
	
	End

	'summary: Use this method to abruptly end current application.<br>The "success" parameter may be set to true or false depending of the cause of the tool being ended.
	Method EndApplication(success:Bool)
		If success Then os.ExitApp(0) Else os.ExitApp(-1)
	End
	
End



ziggy(Posted 2014) [#2]
Also, for a Mojo game, I *think^ this could be a good template. Is it too complete?

Import mojo
Function Main()
	New Game
End

Class Game Extends App

	'summary:The OnCreate Method is called when mojo has been initialized and the application has been successfully created.
	Method OnCreate()
	
		'Set how many times per second the game should update and render itself
		SetUpdateRate(60)
	
	End
	
	'summary: This method is automatically called when the application's update timer ticks. 
	Method OnUpdate()
		
	End
	
	'summary: This method is automatically called when the application should render itself, such as when the application first starts, or following an OnUpdate call. 
	Method OnRender()
		
	End

	'summary: This method is called instead of OnRender when the application should render itself, but there are still resources such as images or sounds in the process of being loaded. 
	Method OnLoading()
		
	End
	
	'summary: This method is called when the application's device window size changes. 
	Method OnResize()
		
	End
	
	'#REGION Code to handle susped status of the game goes here
	
	'summary: OnSuspend is called when your application is about to be suspended. 
	Method OnSuspend()
	
	End
	
	'summary: OnResume is called when your application is made active again after having been in a suspended state. 
	Method OnResume()
		
	End	
	'#END REGION
	
	'#REGION Code to handle game closing goes here:
	
	'summary: This method is called when the application's 'close' button is pressed. 
	Method OnClose()
		Super.OnClose()
	End

	'summary:This method is called when the application's 'back' button is pressed. 
	Method OnBack()
		Super.OnBack()
	End
	
	'#END REGION

End


I don't know if it would be better to just provide OnCreate, OnUpdate and OnRender. Also, notice that the code between #REGION and #END will be collapsed in by the folding, so it won't take a lot of space


therevills(Posted 2014) [#3]
Maybe have two Mojo templates, one complete like your example and a simple one with just OnCreate/Update/Render.


Nobuyuki(Posted 2014) [#4]
Some thoughts:

1. While I like the level of commentary given to some of these for beginners, to more advanced users the level of commenting in a basic template (particularly the entry point file, where the majority of code will go) can become a bit of a nuisance due to the clutter. Power users will probably end up making their own templates without these if you don't give them an option to suppress the 'extra' commentary. This may not be a big deal for the abstract code in commandlineapp; I see that as "library" code.

2. I love the fact you chose Game as the App singleton (this is the same convention I use for my games) in the Mojo example. However, you called its constructor in a way that I believe is disallowed by Strict -- The default ctor should probably have a set of parenthesis after the class name when it's called from Main(). I don't know this for sure, but I believe setting Strict would cause trans to complain at this line.

3. SetUpdateRate(60) is pretty safe, standard stuff to put in OnUpdate() in a template. How about Cls() in OnRender()? Maybe even Cls(0,0,0) if you're catering to newbies...

4. What's your opinion on verbose block closure statements? I know it's not "standard Monkey" but I just wanted to get your opinion of it.


therevills(Posted 2014) [#5]
. Power users will probably end up making their own templates without these if you don't give them an option to suppress the 'extra' commentary.

I agree.

that I believe is disallowed by Strict

I missed that, I would like the templates to be "Strict" by default.


ziggy(Posted 2014) [#6]
Thanks for all suggestions.Other than Mojo game and Command Line tool, do you think we need any additional Monkey template? I don't mean module specific templates, but plain core Monkey templates


Goodlookinguy(Posted 2014) [#7]
I missed that, I would like the templates to be "Strict" by default.


No. Code readability is not lost upon not using Strict. I learned this first hand by doing without it. Unlike BlitzMax there are no real benefits to it.

Other than Mojo game and Command Line tool, do you think we need any additional Monkey template? I don't mean module specific templates, but plain core Monkey templates


Maybe target specific templates? I don't know what they would be.


ziggy(Posted 2014) [#8]
No. Code readability is not lost upon not using Strict. I learned this first hand by doing without it. Unlike BlitzMax there are no real benefits to it.
I agree. While I like that Strict forces parenthesis on Method and function calls, other than that, I think non strict is a lot easier to read. I'll go with non strict to begin with, and maybe I'll add Strict templates later, but I'll do them marked as such.


ziggy(Posted 2014) [#9]
What about this for a simple JungleGui application (that is, not a game with a gui on top of it, but a pure gui only application):


'This is required for this monkey document to be able to recieve Events form JungleGui:
Import junglegui
#REFLECTION_FILTER+="${MODPATH}"

Function Main()
	ExecuteApp(New MyApplication)
End

Class MyApplication Extends WindowFrame
 
	Method OnInit()

		Self.Event_ParentResized.Add(Self, "AppCanvasResized")

		'Add any additional initialization of gui components here:
	
		
	End
	
	Method AppCanvasResized(sender:Object, e:EventArgs)
		'This will make our JungleGui application container to fill the whole application size:
		Local currentGui:= JungleApp.gui
		Self.Position.SetValues(currentGui.DeviceToGuiX(0), currentGui.DeviceToGuiY(0))
		Self.Size.SetValues(currentGui.DeviceToGuiX(DeviceWidth), currentGui.DeviceToGuiY(DeviceHeight))
	End
	
		
End



Tibit(Posted 2014) [#10]
Ziggy, does that setup a project with JungleGUI installed and that code in the main file - all ready to go? That I would like a lot. A suggestion is to also add a button or something simple, to let the user "get going" - a few lines that is trivial to remove but helps with initial debugging for the first steps.


ziggy(Posted 2014) [#11]
Ziggy, does that setup a project with JungleGUI installed and that code in the main file - all ready to go?

Well, it'll work this way:
1.- Jungle Ide will come with some "core" templates you can use out of the box, but they'll be just related to Monkey built-in modules. (Mojo Game, Command line tool)

2.- Any module will be able to provide its own collection of solution templates. Just adding a folder into the module (with a specific name) will make Jungle Ide show all the module available templates when a new solution wizard is run. So, JungleGui will have a set of templates. If you install the JungleGui module, you'll be ableto use them.

That opens the door to any module developer to provide a set (or a single) solution with a basic project setup to get going.

3.- Also, any module can register file templates (no solution templates, but single file templates). So, in any project, you could add a new file based on a pre-made file template.

4.- I would also (maybe not in next version) allow modules to define code snippets, so when you're editing code in a file that directly or indirectly imports a given module, you can be able to import pre-made code samples. As instance, a button creation on a Gui module, or a Tiled loader if you're using Diddy, etc... (not sure still how to make this, but it'll come).

5.- Last part of "the plan" is to create a decentralized module repository, more to come about this later. My idea is to make it using Monkey and JungleGui, but it would be faster to develop it using Java, so not sure still about this. It has to be open source, cross platform, etc...


Nobuyuki(Posted 2014) [#12]
Will module authors be able to write a project/solution template to plug into the new solution screen, too? Would be mainly useful for frameworks, setting up the basic state machine etc in addition to mojo project, commandline etc


ziggy(Posted 2014) [#13]
Will module authors be able to write a project/solution template to plug into the new solution screen, too?
Of course, that's the idea! and distribute them with the modules in a way that no action is required from the module users. Just imagine: Install a new module and all module templates appear in the New Solution wizard. I have this currently working, just solving some small issues here and there.


therevills(Posted 2014) [#14]
No. Code readability is not lost upon not using Strict.

Strict isn't about readability, its to force good coding practice and helps stops silly mistakes.


Samah(Posted 2014) [#15]
@therevills: Strict isn't about readability, its to force good coding practice and helps stops silly mistakes.

+1


Goodlookinguy(Posted 2014) [#16]
Strict isn't about readability, its to force good coding practice and helps stops silly mistakes.


Like? Cause I haven't had any of these silly mistakes that you're implying people have and I've written a lot of code. The only thing I had issues with was the spacing of a function and its parameters. Seen in this link. However, even with strict on that problem is still there because strict doesn't force print to have parenthesis around it. Also, good coding practices is a bulls**t term people use to describe how to never complete projects. People that preach it usually haven't completed much. Looking at my website, I've completed tons of projects and most only partially followed that nonsense. Because getting the job done is more important than how it's done.


ziggy(Posted 2014) [#17]
Yes, honestly, what mistakes does Strict prevent? (just being curious)


therevills(Posted 2014) [#18]
Also, good coding practices is a bulls**t term people use to describe how to never complete projects.

Please don't take this the wrong way, but I take it you don't work in a professional coding environment? And I preach it because it is good practice and I do work as a professional developer... also I have finished several commercial games as a "hobby" which has been released on portals such as Big Fish Games etc.

what mistakes does Strict prevent

Just a quick example:
Function Main()
	Local floatOrInt1 = 3.11434
	Print floatOrInt1
	
	Local floatOrInt2 := 4.2456
	Print floatOrInt2
End



Goodlookinguy(Posted 2014) [#19]
Please don't take this the wrong way, but I take it you don't work in a professional coding environment?


Wrong. Although at the moment I'm jobless, but that's a different problem.

And I preach it because it is good practice and I do work as a professional developer


I've never seen a big project that doesn't look like someone kept throwing in crap during deep development. I don't know where you work but average development doesn't involve college and university style pretty code. More often than not kludges are the way to solve problems.

As for your example, I've never had that problem. := and = are different operators. It'd be like mixing up += or -= with =. They're all different ops so it's not really a big problem if you can read the language.

...also I have finished...


I said "usually." I wasn't strictly talking about you. More like the people who usually mention it are coming fresh out of a college or university with no real experience.


therevills(Posted 2014) [#20]
Sorry Ziggy for taking this thread off topic.

@GLG - We will have to agree to disagree, I will always suggest using Strict and you can suggest not using Strict.


ziggy(Posted 2014) [#21]
Function Main()
	Local floatOrInt1 = 3.11434
	Print floatOrInt1
	
	Local floatOrInt2 := 4.2456
	Print floatOrInt2
End
Is this the only possible "confusing" thing of not using Strict? I could make the IDE show a sort of waveline-like error when assigning a float point value to an integer. That would be nice to have,


ordigdug(Posted 2014) [#22]
Recommendation: I think the idea of two templates one simple (for new monkeyX users and beginning programmers) and one complex is the way to go. Use Strict, don't use coding shortcuts, add commits for newbies (power users will use their own templates most of the time), I would even add to each End statement (End Function, End Method, End Class, End if, etc...). Just my thoughts, based on what would have helped me when I first starting using monkeyX and not having much of a programming background.


ziggy(Posted 2014) [#23]
A beta of Jungle IDE with full support for solution templates and automated SDK installs is being tested. So release is near :D


Goodlookinguy(Posted 2014) [#24]
Is this the only possible "confusing" thing of not using Strict? I could make the IDE show a sort of waveline-like error when assigning a float point value to an integer.


Just make sure it's only when it's a value. I don't want "Local m = 150.5 / 44.7" to result in a red line since I do things like this on purpose. Or make it an optional feature.

Edit: Uh, my example of what I do was not clear. This is what I do on purpose...

Local a := 150.5
Local b := 44.7
Local m = a / b


I don't want a red line under it because I'm dividing two floats which will result in a float.

Edit 2: Maybe use a different color too, other than red. Like orange or blue. Something that makes it like it's not as bad as a breaking bug.


ziggy(Posted 2014) [#25]
Maybe use a different color too, other than red. Like orange or blue. Something that makes it like it's not as bad as a breaking bug.
No ETA for this, and it will definitivelly be used ONLY when an integer is assigned a float literal (no expressions) and also it'll be using a soft color. I plan on add the same kind of mark when a class in a file has the same name as the file it is defined, including casing. Typical newbie problems of having a "myclass.monkey" with a class called "myclass" and having identifier clashes problems.


Goodlookinguy(Posted 2014) [#26]
Ah, very nice. Alright, keep it up.

Off topic: Oh, did you see this small feature request I made?


therevills(Posted 2014) [#27]
Is this the only possible "confusing" thing of not using Strict?

Nope, in that example there is another confusing issue which is harder to see if you dont know about it. Main actually returns an Int, yet without Strict you cant see it and you dont "need" to supply the return statement.
Strict 
Function Main:Int()
	Local floatOrInt1:Float = 3.11434
	Print floatOrInt1
	
	Local floatOrInt2 := 4.2456
	Print floatOrInt2
	Return 0
End

Also when working with multiple developers Strict helps to maintain a good coding standards.


Goodlookinguy(Posted 2014) [#28]
Any variable that's not given an explicit type is int and any function of type int that doesn't return an explicit value returns 0. I don't see how that's something that'll confuse people by not seeing it. The only person who seems to be confused here is you.

Also when working with multiple developers Strict helps to maintain a good coding standards.


The developers over at the very popular php would like to have a word with you about good coding standards.

Jokes aside, I work with multiple developers and whether or not Strict is there or not does not help nor hurt anyone. And by working with Strict code you're actually limiting your ability to read all Monkey code. Hence why you might find that code you put confusing, whereas it's not confusing to me at all.


ziggy(Posted 2014) [#29]
AFAIK Main does not return anything. To give the OS an ERRORLEVEL you need to use a function from the OS module. Lots of functions on Mojo are also declared as Int but the zero returned has no functionality and I find this rather confusing.

EDIT: ExitApp is the function I was talking about.


Nobuyuki(Posted 2014) [#30]
Strict isn't about readability, its to force good coding practice and helps stops silly mistakes.


I thought it was about producing cryptic and pedantic error messages more than forcing good coding practice and stopping silly mistakes. How's a beginner is supposed to know what type is OK to specify in an EachIn when trying to get an enumerator from Map<K,V>.Keys when the return type is "MapKeys"? Then there's the issue of Length sometimes requiring () at the end of it and sometimes not. The error messages for these types incidents are particularly unhelpful when Trans can't point to the specific char on the line it's annoyed with..

Return types for Int functions in Main() and mojo events can be annoying, although that's just a matter of personal laziness. The only reason I can imagine using Strict for is to prevent not specifying a vartype or return type. Sometimes people forget this defaults to Int and won't be caught in some cases at runtime if something other than an Int is assigned to it. Undefined behavior and all that = bad.

IMHO, good coding practice in Monkey is to close your code blocks verbosely, and never use vartype sigils. AFAIK Strict enforces neither of these, so to me, it's just a useless bit of one specific type of 'correctness pedantry'. And unlike following "good coding practice" guidelines in templates, Strict further enforces the user to do the same, regardless of their coding style. No sir, I don't like it.

Disclaimer: Currently working on large codebase with major contributions from ~4 people. Only a few modules are Strict, and this was mainly to be "extra safe" when writing the code because it couldn't go through as many testing cycles before it was required to go into production builds. Most of our code is not written with Strict in mind, and this affords a little flexibility in the syntax, like more terse 'Enum' class members, and less guesswork on whether things like a Length field (for example) is a Field/Property or Method.


therevills(Posted 2014) [#31]
@Nobuyuki, your arguments were good until this point:
Only a few modules are Strict, and this was mainly to be "extra safe" when writing the code because it couldn't go through as many testing cycles before it was required to go into production builds

If all you said is true you wouldn't need to be "extra safe".

I prefer Strict and I know quite a few other coders do too, its a preference that is all. If Monkey had one way of coding we wouldn't even be discussing it. I think that is one of the few things wrong with the language is that it is too loose (again someone could argue that it isn't an issue).

I work in a team with 30 odd developers developing enterprise applications with a strict coding style and I can see the benefits with doing so and that has filtered thru to my "hobby" coding.


ziggy(Posted 2014) [#32]
I've already done what I think will be the built-in template for next Jungle Ide update. There will be:
[*] A empty solution template
[*] A Mojo Game template
[*] A Mojo Game (Strict) template
[*] A Command Line Tool template

The command line tool is not strict, but it's written with all return sentences, etc. so it is strict "compatible".

That said, any user can write their own templates, so I hope my choices are correct for everyone.

Also, notice that solution templates can also include media files, and a data folder. Everything (from solution name, to project name, to main file name) will be renamed and refactored in the XML solution and project files when the template is applied. Also, code folding status on files will be persisted, so you can include folded code to make the template properly organized.

I'm almost ready for a release. Just thinking on adding also a file templates mechanism on next version (and delay it) or release it as is, and add single file templates on next iteration.


Nobuyuki(Posted 2014) [#33]
@therevills
If all you said is true you wouldn't need to be "extra safe".


I don't. This is what some of the others did because it made them feel safer. I personally don't bother, and I'm not too sloppy so no one else seems to mind.


therevills(Posted 2014) [#34]
@Nobuyuki - fair enough, but if I were you I would stick to one set of coding standards and not mix them up as if you have a new coder jumping on board and they see one file as Strict and another not it will be confusing to them.