RE: Help me with my new website!
February 2, 2018 at 8:59 pm
(This post was last modified: February 2, 2018 at 10:57 pm by KevinM1.)
You can cut down a lot on the CSS with shorthand properties: https://developer.mozilla.org/en-US/docs...properties I haven't taken a good look at the JavaScript, but if you find yourself repeating a lot of code, put it in a separate function and invoke it where needed.
Also, you really shouldn't stuff everything into one HTML file. Separate it into at least three files:
1. CSS file
2. HTML file
3. JS file
It makes it a lot easier to maintain/debug/edit/etc.
By placing the game script at the end of the document, you eliminate any runtime issues you may have as you're ensured that the document is loaded. You won't get those errors stemming from undefined DOM objects. And by placing it in a separate file, you create a clear separation of concerns. Your HTML should be blissfully unaware of anything aside from HTML. Similarly CSS and JavaScript.
EDIT: as you progress with your apps, you should look to use automated testing. Every language has at least one testing suite (here's JavaScript's: https://qunitjs.com/ ... I use PHPUnit for PHP). Basically, you set something up, like a function, import it into the testing environment (which is really just another script), and then attempt to use it in the context of the test. The testing environment has special helper functions, typically named assert<something>, that are the actual tests themselves.
So, say you have a function that, at the end, is supposed to return the number 10. You'd run the function and test it:
While this example is trivial, unit testing is a useful practice to get into. I'm in the process of writing my own tests for my e-commerce PHP project so I can verify that the ORM (Object-Relational Mapper... it's middleware that converts OOP objects into database entries, and back again) entities I've setup are working properly. It's a lot better/easier to do it in a test environment (and a secondary sqlite db) than running it in production.
Also, you really shouldn't stuff everything into one HTML file. Separate it into at least three files:
1. CSS file
2. HTML file
3. JS file
It makes it a lot easier to maintain/debug/edit/etc.
Code:
<!DOCTYPE html> <!-- this tells the browser you're using HTML5/want the document to be parsed in standards mode -->
<html>
<head>
<title>Blah</title>
<link href="styles.css" rel="stylesheet">
<script src="jquery.min.js"></script>
</head>
<body>
<!-- all your html -->
<script src="game.js"></script>
</body>
</html>By placing the game script at the end of the document, you eliminate any runtime issues you may have as you're ensured that the document is loaded. You won't get those errors stemming from undefined DOM objects. And by placing it in a separate file, you create a clear separation of concerns. Your HTML should be blissfully unaware of anything aside from HTML. Similarly CSS and JavaScript.
EDIT: as you progress with your apps, you should look to use automated testing. Every language has at least one testing suite (here's JavaScript's: https://qunitjs.com/ ... I use PHPUnit for PHP). Basically, you set something up, like a function, import it into the testing environment (which is really just another script), and then attempt to use it in the context of the test. The testing environment has special helper functions, typically named assert<something>, that are the actual tests themselves.
So, say you have a function that, at the end, is supposed to return the number 10. You'd run the function and test it:
Code:
QUnit.test( "MyFunc test", function( assert ) {
assert.equal( myFunc(), 10, "Passed!" );
});While this example is trivial, unit testing is a useful practice to get into. I'm in the process of writing my own tests for my e-commerce PHP project so I can verify that the ORM (Object-Relational Mapper... it's middleware that converts OOP objects into database entries, and back again) entities I've setup are working properly. It's a lot better/easier to do it in a test environment (and a secondary sqlite db) than running it in production.
