-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Funny :)
- Thread starter Erel
- Start date
- Similar Threads Similar Threads
Debugging involves problem solving. It's an adventure of sorts. In a way one can think of oneself as Indiana Jones by the computer - The Hunt For The Crash. Everybody wants to be Indiana.
Reading documentation is something a boring professor would do. Nobody wants to be that guy.
Reading documentation is something a boring professor would do. Nobody wants to be that guy.
It is globally correct
When the next Beta comes, I bet many would find it interesting reading about it. If you feel like expanding on it a bit, of course.
Ain’t that the truth 
?!
?!
It is truth for me
For all of us...t is truth for me
I don't really agree.
Let's take a B4X project for example. Should I read ALL the documentation to fix a bug? Lots of topics that have nothing to do with it?
No, I read any error message or the line that triggered it. Then I could possibly read the documentation, but often it is not necessary, it is sufficient to search on the site.
Today you can even ask ChatGPT what the error could be.
In short, it is not true that it is more important and simpler to read the documentation, it is better to carry out well-done debugging (unless you do not know at all the language you are using; in this case it is better for you to go fishing
)
Let's take a B4X project for example. Should I read ALL the documentation to fix a bug? Lots of topics that have nothing to do with it?
No, I read any error message or the line that triggered it. Then I could possibly read the documentation, but often it is not necessary, it is sufficient to search on the site.
Today you can even ask ChatGPT what the error could be.
In short, it is not true that it is more important and simpler to read the documentation, it is better to carry out well-done debugging (unless you do not know at all the language you are using; in this case it is better for you to go fishing
)
Hmm... Fishing... ?... is there any documentation?I don't really agree.
Let's take a B4X project for example. Should I read ALL the documentation to fix a bug? Lots of topics that have nothing to do with it?
No, I read any error message or the line that triggered it. Then I could possibly read the documentation, but often it is not necessary, it is sufficient to search on the site.
Today you can even ask ChatGPT what the error could be.
In short, it is not true that it is more important and simpler to read the documentation, it is better to carry out well-done debugging (unless you do not know at all the language you are using; in this case it is better for you to go fishing
As I have mentioned, the keyword is sometimes.
You may be lucky to get a solution by trial and error, which happened to me most of the time that sometimes I don't even understand what I am doing. Sometimes I am out of luck.
Sometimes we took longer time to find a solution which we didn't realize and expect.
You may be lucky to get a solution by trial and error, which happened to me most of the time that sometimes I don't even understand what I am doing. Sometimes I am out of luck.
Sometimes we took longer time to find a solution which we didn't realize and expect.
And after you spent hours on reading these 120 pages you will hit a wall trying to understand why it doesn't work. Turns out that the API or SDK was sunsetted 3 years agoHow about
"5 minutes of debugging can sometimes help you to save 5 hours of reading the documentation"?
Note: "sometimes"
Sometimes I need 1 hour to read a page (or a paragraph) of documentation, where the documentation is like 120 pages.
I've been in this situation myself. I tried to send a request to the API only to find out that their SSL has expired 3 years ago.