It is currently Thu Dec 14, 2017 3:10 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Mar 29, 2017 7:26 pm 
Offline

Joined: Mon Jan 30, 2017 5:20 pm
Posts: 303
Location: Colorado USA
My way of programming is just type up whatever comes through my head. And that usually works in the beginning, but once my code starts to become more complicated, I begin to forget what each part of the code is doing, I end up having a whole lot of headers, I forget what jumps where, why it jumps where it does, why it's working with the numbers it's working with, and so on. Is there a way to avoid confusion?


Top
 Profile  
 
PostPosted: Wed Mar 29, 2017 7:35 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19342
Location: NE Indiana, USA (NTSC)
Write pseudocode first to get an idea of what the code should look like.


Top
 Profile  
 
PostPosted: Wed Mar 29, 2017 7:47 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Sounds like you need to comment your code better.


Top
 Profile  
 
PostPosted: Wed Mar 29, 2017 8:21 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2425
Print your code on a piece of paper and draw arrows where all the branches are, and see if you can untangle it. Also circle duplicate code you can find, because you can use either a subroutine or macro for it.


Top
 Profile  
 
PostPosted: Wed Mar 29, 2017 9:38 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2806
You should comment your code and structure things in a way that makes sense. In the moment that you are writing code you can be pretty sloppy and get away with it because at the time you know what you are trying to accomplish. Or your goal is small enough that you won't get in trouble being messy. But when you move onto bigger projects you really should think about good structure and comments. Having useful subroutines or dividing tasks into different ones and having comments describing what each function aims to achieve will help.


Top
 Profile  
 
PostPosted: Wed Mar 29, 2017 10:14 pm 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 262
In the modern era you can name labels and variables with long meaningful things.
Code:
checkCollisionWithTreeParts
;did they hit the tress
   ldx #0
   stx ShotVars.hitTree
_testY
   lda TreeCollRectsY,x ; check top y
   cmp ShotVars.y
   bcs _miss
   lda TreeCollRectsY+1,x ; check bottom y
   cmp ShotVars.y
   bcc _next
   ; we are in range of the Y
   lda TreeCollRectsX,x ; check left side
   cmp ShotVars.x
   bcs _next
   lda TreeCollRectsX+1,x ; check right side
   cmp ShotVars.x
   bcc _next
   #STN ShotVars.hitTree ; record that we hit
   rts
_next
   inx
   inx
   cpx #12
   bne _testY
_miss
   rts

I don't know what assembler you are using so its hard to comment on its abilities but don't use magic numbers, use labels as well. I like to add a 'k' to the front of mine so I know they are a Constant. My assembler (64tass) allows me to make blocks to group them together like so
Code:
kHud .block
   Pointers .block
      HitBirds = kVectors.charBase+(21*40)+16   
      Bullets = kVectors.charBase+(21*40)+4
      RoundNumbers = Bitmap+(19*320)+(6*8)
      RoundNumbersScreen = kVectors.charBase+(19*40)+6
      ShotTextScreen = kVectors.charBase+(22*40)+4
      BirdsNeededScreen = kVectors.charBase+(22*40)+16
   .bend

   Colours .block
      BirdNotShot = $10
      BirdFlash = $00
      BirdShot = $20
      BulletShot = $00
      Bullet = $F0
      Sky = $03 ; cyan
      FlyAwaySky = 10 ; pink
      RoundNumber = $50
      RoundEmpty = $99
      ShotTextNormal = Sky<<4
      ShotTextFlyAway = FlyAwaySky<<4
   .bend
   
   Values .block
      NumBirds = 10
      NumBullets = 3
   .bend
.bend

And then in code I can do
Code:
lda #kHud.Colours.Sky
sta SkyColour

So the comments basically write themselves.


Top
 Profile  
 
PostPosted: Wed Mar 29, 2017 10:21 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Also, be consistent in your choices. Try to solve similar problems using similar solutions, so it's easier for you to recognize programming patterns later. For example, when simulating high-level constructs like IF, FOR, WHILE, etc., try to follow the same conventions every time, so you can easily recognize these blocks in the future instead of spending time trying to make sense of what appears to be spaghetti code.

Like I said before, comment the hell out of your code. I don't mean pointless comments like "load A with 32" or "clear the carry" every freaking line for things that are obvious from the instructions themselves, but general descriptions of what each block of code is doing.

Code:
   ;fill MyArray with the first 8 multiples of 16
   ldx #$07
   lda #$70
   sec
Loop:
   sta MyArray, x
   sbc #$10
   dex
   bpl Loop

Everything I do is organized in blocks like this, that I separate by complexity and purpose, and each block has a comment describing what it does.

I also greatly dislike huge source files that I have to scroll through to find a piece of code, so I always put each subroutine, interrupt handler, table, etc. in its own file, and have the main file include all the files in the appropriate order. Each of these files has a header, detailing what it contains. Subroutines have explanations about input parameters, return values, and registers/variables that are modified.


Top
 Profile  
 
PostPosted: Thu Apr 20, 2017 2:52 am 
Offline

Joined: Wed Nov 30, 2016 4:45 pm
Posts: 93
Location: Southern California
Very good advice above. I would comment that no matter how experienced you are, it is easy to lose control of a project if you don't always try, even from the beginning, to always be more structured, more neat, improve your commenting, etc..

I've been a macro junkie since about 1986 or '87. Macros can do a lot to make your source code more concise. In my assembly-language programming, I had wanted to use program structures from higher-level languages for years, but figured out how to do it only a few years ago using macros. It made things so much easier, and made assembly language so much more of a pleasure!! The majority of labels are gone, and the spaghetti is gone. I wrote it up in a section of my website, at http://wilsonminesco.com/StructureMacros/ . It starts with the basics of what macros are and how to use them, before getting into the structure macros themselves. People often think macros will be very inefficient; but in most cases, the macro will assemble exactly the same machine code you would have gotten without them, except that their usage will reduce bugs, and may also actually help you write more-efficient code. This is because you can see what you're doing better.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Top
 Profile  
 
PostPosted: Thu Apr 20, 2017 7:34 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 461
Location: Denmark (PAL)
psycopathicteen wrote:
Print your code on a piece of paper and draw arrows where all the branches are, and see if you can untangle it. Also circle duplicate code you can find, because you can use either a subroutine or macro for it.


Image

Also don't forget to wrote "TODO"-comments everywhere you're writing sloppy routines that need to be tightened up later. :P

Seriously though, even though it sounds simple, Oziphantom's suggestion should be taken seriously. I still see "old school" programmers sticking to confusing abbreviations and short names for variables and labels. That stuff just isn't necessary. Especially for compiler/assembler stuff that's not even going to affect your eventual build.

Another way I've found to make my own code more manageable is using a lot of macros with similarly easily understandable names. Even when I'm only including the macro in one place, it makes the code for that specific area/routine much more easy to read when I return to it later, effectually breaking my code up into manageable bits without the overhead caused by subroutines.


Top
 Profile  
 
PostPosted: Thu Apr 20, 2017 9:16 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3968
Sometimes you can write the comments, then write the code afterwards.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Thu Apr 20, 2017 9:29 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
My source files have tons of "TODO" comments I can easily search for, as I often rush through the boring parts to get to the interesting stuff quicker! I try to make the sloppy stuff as obvious as possible, so that there's absolutely no chance of me forgetting​ to change it later.


Top
 Profile  
 
PostPosted: Thu Apr 20, 2017 9:39 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19342
Location: NE Indiana, USA (NTSC)
Until you just throw your hands up in frustration:
Code:
; TODO: tudo


Or if you lived in another South American country, the joke would be even easier:
Code:
; TODO: todo


Top
 Profile  
 
PostPosted: Thu Apr 20, 2017 10:04 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 461
Location: Denmark (PAL)
tokumaru wrote:
My source files have tons of "TODO" comments I can easily search for, as I often rush through the boring parts to get to the interesting stuff quicker! I try to make the sloppy stuff as obvious as possible, so that there's absolutely no chance of me forgetting​ to change it later.


I'm glad I'm not the only one with this habit. :P
At work though, we do have a guideline that says no "TODO" comments or similar should make it through code review, and it's been working out exceptionally well. The more you focus on your goals (which you should), the more likely you are to forget about technical debt (which you shouldn't).
If I had to give a serious estimate I would assume it's unlikely that more than 30% of the "TODO" lines in my current NES project will ever get the attention they should. Of course, it's all a question of premature optimization and profiling. Priorities.


Top
 Profile  
 
PostPosted: Thu Apr 20, 2017 10:36 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
tepples wrote:
Code:
; TODO: tudo

Yup, it happens!

Quote:
Or if you lived in another South American country, the joke would be even easier:
Code:
; TODO: todo

That kinda still works in portuguese too, as "todo" means "all" or "whole". But yeah, "tudo" ("everything")works better in a to do list.


Top
 Profile  
 
PostPosted: Fri Apr 21, 2017 7:39 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2425
Sumez wrote:
psycopathicteen wrote:
Print your code on a piece of paper and draw arrows where all the branches are, and see if you can untangle it. Also circle duplicate code you can find, because you can use either a subroutine or macro for it.


Image

Also don't forget to wrote "TODO"-comments everywhere you're writing sloppy routines that need to be tightened up later. :P

Seriously though, even though it sounds simple, Oziphantom's suggestion should be taken seriously. I still see "old school" programmers sticking to confusing abbreviations and short names for variables and labels. That stuff just isn't necessary. Especially for compiler/assembler stuff that's not even going to affect your eventual build.

Another way I've found to make my own code more manageable is using a lot of macros with similarly easily understandable names. Even when I'm only including the macro in one place, it makes the code for that specific area/routine much more easy to read when I return to it later, effectually breaking my code up into manageable bits without the overhead caused by subroutines.


That's either Billy from Power Rangers finding where the Zeo Crystals are, or Glen Beck finding the Illuminati headquarters.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group