Timeline for Parsing JSON in one go using state machine solution
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2017 at 12:40 | history | edited | CommunityBot |
replaced http://codereview.stackexchange.com/ with https://codereview.stackexchange.com/
|
|
| Mar 19, 2016 at 19:32 | vote | accept | Lin Ma | ||
| Mar 17, 2016 at 23:36 | comment | added | Tersosauros | Yes, casting the value to an integer is what you need. There was code to do this in my answer to the last version (#2) of this question. The cast will need to be inside a try/except block to ensure that non-integer values are caught and treated as some other type (float for example) - this was the behaviour of the code you based this new code from. | |
| Mar 15, 2016 at 3:01 | comment | added | Lin Ma |
Thanks Tersosauros, I accepted all of your comments, and to fix the integer type issue, I think I can fix by using int(lastValue) to convert the value directly? How do you think? Thanks.
|
|
| Mar 14, 2016 at 15:33 | comment | added | Tersosauros |
Yes, as I said in my previous comment on the question: "you should generally only ever need to track one state per FSM. So since all your logic is contained within one, you would need only one state variable." The only BIG problem with this code is the broken integer handling - the other issues (variable names, a repeated test condition, and one 4-line repeated block of code) are fairly minor. Although, as a review site, they are warranted for this.
|
|
| Mar 14, 2016 at 8:05 | comment | added | Lin Ma | Thanks Tersosauros, agree with all of your comments. I want to confirm in general you think using one state variable is fine, comparing using two state variables for the state machine? | |
| Mar 14, 2016 at 6:43 | history | answered | Tersosauros | CC BY-SA 3.0 |