inherit
194230
0
Nov 21, 2015 5:56:42 GMT -8
Alan Vende
4,215
May 2013
l1o2u3i4s5
|
Post by Alan Vende on Oct 24, 2014 13:43:54 GMT -8
This post is a double post -- for my question, as well as to learn more about JS itself. Thank you in advance for your help. I want to create a Plugin, and I noticed that in the Tutorial that I'm working on that was given to me by Chris, and I have come into some problems with it; it gave me a Syntax error. My questions are: 1. Would Proboards tell me if I have a bug, like where I have one, or do I have to figure that out on my own? 2. The instructions for this part of the video are these: "Data Types I & II: Numbers & Strings Data comes in various types. You have used two already! a. numbers are quantities, just like you're used to. You can do math with them. b. strings are sequences of characters, like the letters a-z, spaces, and even numbers. These are all strings: "Ryan", "4" and "What is your name?" Strings are extremely useful as labels, names, and content for your programs. To make a number in your code, just write a number as numerals without quotes: 42, 190.12334. To write a string, surround words with quotes: "What is your name?" Instructions Write a string with at least 3 words. Check out the examples of strings above. Find the length of the string by writing a period (full stop) and the word length, like this: "string".length. Length counts every character in the string - including spaces!"
I'm working on this line of JS for this exercise: "Lou is awesome" (Egotistical, I know, but it said three words! ). It's giving me a Syntax error when I type in this:
"Lou is awesome" "string".length I think I'm doing it correctly, but it's still giving me a Syntax error, yet I'm trying it over and over again with variations in the String department, and it still doesn't work.
I got it when I put in "Lou is awesome".length -- I read it wrong, I guess.
This thread is now an example of: You better read coding carefully; if you have something wrong with it, you're going to want to make sure that you can figure out what you're doing. Or, as my family says, "You have to be smarter than the thing you're working with!"
So, my question to you all is: Do you have any suggestions for making sure I don't do anything wrong in coding, and when I do, to figure out where the "bug" is?
Thanks!
|
|
inherit
Official Code Helper
65613
0
1
Oct 22, 2024 1:56:19 GMT -8
Chris
"'Oops' is the sound we make when we improve"
9,022
December 2005
horace
RedBassett's Mini-Profile
|
Post by Chris on Oct 24, 2014 15:04:08 GMT -8
So, my question to you all is: Do you have any suggestions for making sure I don't do anything wrong in coding, and when I do, to figure out where the "bug" is?
Thanks! As with anything in life worth doing, the experience of failing teaches more than succeeding ever will. The one who has failed at something in the past naturally has a greater detailed map of the pitfalls than the person who got it right on the first try and moved on. When you finally succeed you will know more than the guy that got lucky the first time out the gate and you will have powers the Dark Lord knows not. So not doing it wrong in coding should not be the objective here but rather the objective should be finally getting it right and in the process knowing what not to do the next time (your string length story being a perfect example). All browsers come with a console that lets the user know what errors it encountered during the processing of the webpage. This would be your primary source for knowing if things went horribly wrong ("bug") and modern browsers will even give you an exact location of where the error occurred so you could go to that line and see for yourself. Now this is where the benefits of all that trial-and-error failing in the past really shines since you have intimate knowledge of what NOT to do you can easily pick out what went wrong in that line. Proboards itself also has checks in place to test for error conditions in certain places and will intercept and notify about such caught exceptions, however like with any other software, as it is with Heinz ketchup, it's all about the anticipation. Writing Code involves anticipating conditions that can occur before they actually occur so you can put some action in place to deal with whatever just occurred. Sadly not every possible scenario can be accounted for or may not even be desirable to account for if they are rare enough and would serve only to bloat the code unnecessarily or perhaps you just didn't think of them. Anticipating every possible move even in situations where the possible moves are finite can be daunting so we generally fallback to statistics in order to filter out the exotic scenarios that have a probability of occurring once every 2.3 million years and probably wouldn't need attention in our lifetime or in the lifetime of our great-great-great grandchildren. ETA:
An insurance company could very well sell Glacier Collision Insurance for houses and automobiles in the Wisconsin area since it's been scientifically demonstrated that glaciers roamed these streets causing pure mayhem: running stop signs, scaring pedestrians and and tipping over the scooter-riding elderly population approximately 11,000 years ago. However, since the likelihood of that event reoccuring within our lifetime is a pretty slim it would make no sense to offer that as a supplemental insurance option by any company and any Wisconsin homeowner having this knowledge, passed down through generations, of these marauding glaciers would laugh at such a sales pitch knowing that such events have not occurred in millennia and not likely to occur within the lifetime of their house. However, if that event was to suddenly occur tomorrow then that would be a "bug" in the system.
|
|
inherit
194230
0
Nov 21, 2015 5:56:42 GMT -8
Alan Vende
4,215
May 2013
l1o2u3i4s5
|
Post by Alan Vende on Oct 24, 2014 16:04:19 GMT -8
So, my question to you all is: Do you have any suggestions for making sure I don't do anything wrong in coding, and when I do, to figure out where the "bug" is?
Thanks! As with anything in life worth doing, the experience of failing teaches more than succeeding ever will. The one who has failed at something in the past naturally has a greater detailed map of the pitfalls than the person who got it right on the first try and moved on. When you finally succeed you will know more than the guy that got lucky the first time out the gate and you will have powers the Dark Lord knows not. So not doing it wrong in coding should not be the objective here but rather the objective should be finally getting it right and in the process knowing what not to do the next time (your string length story being a perfect example). All browsers come with a console that lets the user know what errors it encountered during the processing of the webpage. This would be your primary source for knowing if things went horribly wrong ("bug") and modern browsers will even give you an exact location of where the error occurred so you could go to that line and see for yourself. Now this is where the benefits of all that trial-and-error failing in the past really shines since you have intimate knowledge of what NOT to do you can easily pick out what went wrong in that line. Proboards itself also has checks in place to test for error conditions in certain places and will intercept and notify about such caught exceptions, however like with any other software, as it is with Heinz ketchup, it's all about the anticipation. Writing Code involves anticipating conditions that can occur before they actually occur so you can put some action in place to deal with whatever just occurred. Sadly not every possible scenario can be accounted for or may not even be desirable to account for if they are rare enough and would serve only to bloat the code unnecessarily or perhaps you just didn't think of them. Anticipating every possible move even in situations where the possible moves are finite can be daunting so we generally fallback to statistics in order to filter out the exotic scenarios that have a probability of occurring once every 2.3 million years and probably wouldn't need attention in our lifetime or in the lifetime of our great-great-great grandchildren. Thank you for that insight, my friend. I'm doing the JS tutorials that (I think) you gave to me, if I remember correctly. I am almost done with them, but I'm not sure if I'm ready to write code; I'm more ready to create a webpage, because that's what I know how to do best. When something new comes, especially coding, I revert back to what I know instead of branching out and going onto different types of coding. If I find bugs in my coding, I will be able to learn more because in a way, I have made a mistake, and we all learn from mistakes. I just don't know if I should attempt to create a Plugin, have people test it, and see if there's anything wrong with it, or keep learning about JS. I know I'm kind of "jumping the gun", I guess you could say, but is it wrong for someone to want to see what they know and then go back and change what's wrong?
|
|
inherit
Official Code Helper
65613
0
1
Oct 22, 2024 1:56:19 GMT -8
Chris
"'Oops' is the sound we make when we improve"
9,022
December 2005
horace
RedBassett's Mini-Profile
|
Post by Chris on Oct 24, 2014 16:42:20 GMT -8
I know I'm kind of "jumping the gun", I guess you could say, but is it wrong for someone to want to see what they know and then go back and change what's wrong? Nothing wrong with that at all Alan Vende, progress is only made when we leave our comfort zone and reach for higher or different goals than to which we've grown accustomed.
|
|