How to ask a question


#1

Well, the new season is coming and there are going to be an abundance of new threads started asking questions. Here is some info that you should provide that may help people answer your questions:

Detailed description of what is happening that shouldn’t be.
Instead of saying “The robot doesn’t work when I run code X.” Compare what IS happening, to what SHOULD be happening.
eg: The robot’s arm is moving to the third position when it should be lowering.

Well commented, understandable code
This should be your normal coding style, but if not please revise the sections of code that you post. We didn’t write the code, so we have no idea what you are attempting to accomplish with a certain line.

Hardware setup
Is your left side of the drive train connected to PWM port 1? Is the arm potentiometer connected on analog 1 or 2? All of this needs to be specified.

Feel free to add onto this post.


#2

I agree with what you said completely, and would like to thread expand this a little more broadly past programming.

Heres a good tip, supplementing what Mike already said: Give examples, examples, and more examples! All too often ( I’ve done it, I should know) there are posts and threads that go “how do I do this”? How should I lift the tetra? Should I use wheels or tracks? All very good questions, but a bit too general, with no other info. Say for example,

“How are teams holding on to the tetra? We have a spear design that works alright, but what would you suggest as an alternate design?”

Oh, and specific thread titles. Instead of “why is this stuck?”, title it " Fisher Price Gearbox Binding" Just helps with some confusion entering the thread.

These tips are all over the place, but Maybe not in one, question asking thread. Does anyone have a link?


#3

I would like to add that under the readable code act of Yesterday 03:03 PM that variables and classes are easily identified, when looking at your code i dont know the difference between what x, y, z and asdet all mean give varibles meaning,

Also try to space code out if there is a block of code that is an algorithm(sp?) or accomplishes a particular purpose, double space above and below it(comments are great too) and single space inside the block that makes the outside readers life much easier

In addition when you are here for a problem try to give a timeline of what you have tried and how it has worked

ex: I changed this equation to calculate arm positition so that it should move right and now its even less accurate

Thanks,
Cuog


#4

**Spelling and Grammar
**We aren’t asking for much here. Theres no need for your post to read like a 16th century Shakespearean sonnet. Just some basic spelling and grammar. An example:


#5

If you call a function from some where else in your code be sure to post it to. It is impossible to find an error that relates to “do_this_now(do_it_when, Do_it_how)” if we dont know what that function is. Also even though the function may compile fine there is no gauruntee that it isn’t what is causing a problem.

If the problem is a compiling error copy and paste the error straight from mplab, it is very difficult to find out why the code wont compile if all you tell us is “It says something about something being called twice”

Also while Mike said “Theres no need for your post to read like a 16th century Shakespearean sonnet” I would be impressed if you did post in the form of a sonnet (even more so if you could code in sonnet form).


#6

Maybe we should have a contest that runs from ship date to nationals to do exactly that.


#7

Might even qualify for the IOCCC! :yikes:


#8

Heh, cool little thing I found that relates to the whole sonnet thing. It’s called the Shakespeare Programming Language and is a language that is designed so when you write programs, they look like plays.
http://en.wikipedia.org/wiki/Shakespeare_programming_language


#9

Hello all,

I know I’m kindof new to programming, but it might help if when you are showing people your code, you could point out the problem with a different color.

ex.


blah blah blah
blah blah
blah blah blah
blah blah
blah blah

and if you are responding to someone’s problem with code that you fixed you could do the same thing.


#10

That could be less useful than you think. If you can correctly identify where the problem is, you can probably fix it. The trouble is that, most of the time, the problem is that the person trying to make the program work doesn’t know where the problem is.


#11

Also, wouldn’t it help to actually tell the person what IDE they are using (MPLAB, ROBOTC, EasyC ) or, if they aren’t using any, then say that. :]