Coding Efficiency

[Pete]

Yeah, I do know the INKEY$ values for those keys you mentioned, so all I have to do is keep typing. I'd go bonkers doing the ctrl+k thing over and over. Also, I'd have to spend additional time documenting what the hell number just printed is related to. By not repeatedly typing it myself, I'd never learn it, either. Now if I see CHR$(59) in my code, I know it's the second bit returned for the F1 key. I've coded this way so long it is intuitive to me. I guess It's like the old saying goes, "You can't preach a dog new pricks!"

Pete

[TerryRitchie]

Still not a fan of _KEYHIT because part of efficiency to me is how fast I can code. _KEYHIT slows me down. It's not intuitive like INKEY$. 

Actually INKEY$ would be just about perfect for my uses, except for the nagging problem it has identifying when a key is released. It gives false positives and can be problematic without coding a workaround routine, which really is inefficient.

I'm glad we have _KEYHIT and the other QB64 key statements but I'm not sure I will ever get comfortable using them. I don't have youth on my side like Steve. Oh, I won't go into sympathy because us old folks do get plenty of sympathy for that, but Steve, once again beats me in this department, as studies have proven time and time again that sympathy for ugly outweighs age every time!

Pete

I find _Keyhit utterly intuitive anymore.

Quick, what's the INKEY$ key combos for Left Arrow, F1 and Delete?

Want me to give them to you instantly in the IDE for _KeyHit?

CTRL-K, Left Arrow
CTRL-K, F1
CTRL-K, Delete

Just press CTRL-K and then the key, the IDE automatically returns the associated value with that key back into your program where your cursor is located.

Now, what can be any more intuitive than that?? 

Yeah, I have to agree. Since discovering _KEYHIT, _KEYDOWN, and _BUTTON I rarely use INKEY$ any longer. The main problem I have with INKEY$ is that it is tied to the BIOS keyboard rate which simply can't be used for controlling real-time objects on the screen for instance.

Don't get me wrong, INKEY$ is still extremely useful for things like menu selection, etc.. but for gaming _KEYHIT, _KEYDOWN, and _BUTTON are the way to go.

And the CTRL-K shortcut ... amazing addition to the IDE ... I use it all the time.

[Pete]

So here is one based on Ken's Calendar...

Code: (Select All)

Do

    Input "Input a number between 1 and 12"; n%

    If n% > 0 And n% < 13 Then

        If m = 1 Then month$ = "January"

        If m = 2 Then month$ = "February"

        If m = 3 Then month$ = "March"

        If m = 4 Then month$ = "April"

        If m = 5 Then month$ = "May"

        If m = 6 Then month$ = "June"

        If m = 7 Then month$ = "July"

        If m = 8 Then month$ = "August"

        If m = 9 Then month$ = "September"

        If m = 10 Then month$ = "October"

        If m = 11 Then month$ = "November"

        If m = 12 Then month$ = "December"

        Print month$

    Else

        End

    End If

Loop

So to reduce lines, I would code it this way...

Code: (Select All)

month$ = "January  February    March    April    May      June      July    August  September  October  November  December  "

Do

    Input "Input a number between 1 and 12"; n%

    If n% > 0 And n% < 13 Then

        Print LTrim$(Mid$(month$, (n% - 1) * 10, 10))

    Else

        End

    End If

Loop

...but since I don't do speed tests, I can't really say if my example would run any faster. So what do you guys think? Is parsing a string faster than checking 12 conditions? If not, then we can just refer to this as a coding style.

Pete

- Just me parsing around.

[SMcNeill]

Now see, if I was to write that, I'd have to do something like create a function there:


FUNCTION GetMonth$(month)
    SELECT CASE month
        CASE 1: GetMonth$ = "January"
...
END FUNCTION

And then I'd save that forevermore, and just copy/paste it as needed in any application that I ever wrote in the future that needs to convert numeric months to their string equivalent. 

(And YES, if you look, you'll see that I do, indeed, have such a style function in my libraries for months, days, day of week, ect...  )

Write it once.  If it works, use it forever!

[mdijkens]

I work top down, all about clean, readable code. 
Start with main skeleton; creating empty functions that return fixed answers; then filling them in, creating new functions where it makes readability better.
In final stages I start search/replace variable and function names to make it better readable.
If the code is really big (>10k lines) I start pushing blocks to include-files, but then I really miss the old QBX overview of all modules/include under F2

Performance/Efficiency is plenty for 99% of code. Only where it counts (animation, huge I/O), I refactor the code purely towards performance, but even then, only for the smallest parts where it matters.

Oh, and yes, I use Inkey$ a lot (old habits never die)

[Pete]

+1 for "old habit never die"

I miss that former INCLUDE viewing feature, too.

You brought up a great idea that both Steve and I use, but failed to mention... starting out with easy to type variables and when finished, changing the names to longer more descriptive variables. Saves a ton of typing time.

There are times I'd like a monitor 80 inches tall. I'd love to be able to view 500 lines of code at a time. In two cases I can recall I printed maybe a 100+ pages of code, and stuck it to the wall. Steve would say. Great idea, Pete... Then when you run out of toilet paper, ya just grab a sheet of your code and be thankful you put it to a better use!

Pete

[Kernelpanic]

Pete .  ...but since I don't do speed tests, I can't really say if my example would run any faster. So what do you guys think? Is parsing a string faster than checking 12 conditions? If not, then we can just refer to this as a coding style.

With today's CPUs, the difference is probably between 0.00012 and 0.00018 seconds. With about a million lines of source code or so, there could be a delay of one second. 

[justsomeguy]

You know I always want write clean, efficent code, but my muddled brain always ends making thing way more complicated and I feature creep.

I start out thinking about doing this:

Code: (Select All)

FUNCTION GetMonth$(month)
    SELECT CASE month
        CASE 1: GetMonth$ = "January"
...
END FUNCTION

I end up doing this.

Code: (Select All)

month$ = "JanuaryFebruaryMarchAprilMayJuneJulyAugustSeptemberOctoberNovemberDecember."
DO
INPUT "Input a number between 1 and 12"; n%
i% = 1: m$ = "": DO
  n% = n% + (INSTR("JFMASOND.", MID$(month$, i%, 1)) > 0)
  m$ = _TRIM$(m$ + CHR$((ASC(MID$(month$, i%, 1)) * -(n% = 0)) + (32 * -(n% <> 0))))
i% = i% + 1: LOOP WHILE i% < LEN(month$) AND n% >= 0
PRINT m$
LOOP

[Pete]

I love, and do stuff like that, too. I almost posted something very similar with INSTR() but it either would require a look, like your example, and making the string: "01January02February..." etc. Now you have to fiddle with the numbers to get an entry on 1 to be a string as "01" and the efficiency part flies out the Windows, again.

Neat complicated solution to a simple problem though!

Oh, and I'm glad the Kernel's getting his giggles.

Pete

[dano]

My #1 objective is clarity of code.  I like to comment with concise understandable comments (and not write a book!).  I need to be able to come back later and understand my code quickly so that I can make changes.  If I have to spend an hour just trying to get back an understanding of what I was doing, it makes me quite an unhappy person!

I will take a chuck of complex code and assign it to a function even if I only use that function in 2 places (2 uses is my minimum for a function) if it makes my code easier to understand.  All of my code is written for business so cutting edge speed is not of utmost importance...although it is important, I would rather not have spaghetti code even if it means that it might run a tad slower.