Feedback on "Our Simple Coding Approach" section in book about glitch-game-club

[mickfuzz]

@davegoopot hi there,
apart from the use of double quotes - which i agree with - what are your thoughts here.
I've had a bit of negative feedback about the use of global variables but I'm not sure what a better and simple alternative would be.

[mickfuzz]

Hi @davegoopot it would be great to put your thoughts you shared with me on email this thread.

Also - one approach is to not list the variables at the top at all unless they are constants needed for quick editing.

and one with variables taken out - https://hazards-enemies.glitch.me/
This works, but creates a lot of ugly red dot errors saying that the variable hasnt' been defined.

[davegoopot]

Here's the email:

There definitely is a tension here: "proper" web coding is really hard vs. we want to start off programmers with no previous experience and draw them in. I think of it like learning to write poetry: if you focus on the grammar rather than the art then I don't think you are going to be doing a good job of teaching poets.

Can I propose the following code principles as a starting point:

Principles

P1) It should be obvious what the code does
P2) The code should encourage the practice of solving problems by breaking difficult problems into small pieces
P3) Given the choice, write in a style that is easy to change and experiment with, even if that means you write code that is difficult to reuse elsewhere

My experience of web coding in the "real world" is that you have to abandon P3. Any larger project needs to play nicely with many third-party libraries. In the web/JS world that tends to mean jumping through some syntactic hoops to ensure something like namespace segregation for lots of scripts on a page.

Our problem is much easier: write this game and nothing else. Don't worry about clobbering the global namespace for the reason that it makes your code harder to share, because you are never going to share this code. Definitely worry about global variables if it makes the code difficult to understand.

Let me unpack the specifics as I see them:

Feedback #1: Don't use all those global variables

This is I think fair, but not for the reasons of "best practice". I think this line is good:

var gravity=500;

...it is obvious enough what this is for and it is really easy to change right at the top of the file.

This however does feel wrong to me:

var level;
var wlevel;
var level1;
var level2;
var level3;

...I think it is not at all obvious what these lines do at the top of the code. Let me have a think about how to refactor.

Feedback #2: HTML File Structure

Definitely a "whatever" response. Let's try to get the new coders to ignore the HTML file for as long as possible!

Feedback #3: Function Naming

I think they are on to something here. There syntax

update: function() { 

...doesn't read right to my eyes (I have biases here of course!). Again let me have a think how to improve this.

Can I add two more of my own:

(Dave) Feedback #4: Long Blocks of Code

I'd like to see if I can refactor out some functions. My personal preference is to write code by:

First: break up the problem into steps you understand and give a function name to each step (you haven't written those functions yet).

Second: one at a time implement those function steps

(Dave) Feedback #5: Inconsistent indent/brace formatting

I'm a python programmer at heart so my eyes are trained to spot those things

[mickfuzz]

Hi there,
This all seems to be emerging well.
I've created a CODEGUIDE.md file to collate this information into.

I've also created this project https://glitch.com/edit/#!/hazards-enemies-vlinted?path=js/index.js:35:0 which does the following; ( the ones l'm less sure about I'm putting later in the list)

• uses following guidelines - https://www.w3schools.com/js/js_conventions.asp
• as such produces minimal js / es lint warning
• create state object from scratch and use function syntax of playState.create = function () { rather than nested approach
• avoids object literal syntax (one reason to use Phaser 2 rather than 3)
• put variables that can be most manipulated by users to affect game play at start as globals
• puts variables in global if they are needed by more than one function
• lists variables on one line at the start of functions (not sure about this)

We can add in your three above too.

• write code so it is obvious what it does
• write code so it encourages the practice of solving problems by breaking difficult problems into small pieces
• where possible, write in a style that is easy to change and experiment with, even if that means you write code that is difficult to reuse elsewhere - or favour tinker-ability over extend-ability