principles of programming

Talk about anything
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

principles of programming

05 Jan 2019, 19:14

- I tried to collect all of the general principles that I've acquired over time, that would have been useful to know when I started programming.
- I started a txt file, added ideas to it every so often, then I felt I had enough material to shape into a document, the difficulty came in figuring out how to group the principles.
- Some are my own, some are well-known, and some are a mixture. I also provide some links at the end.
- Do offer additions/alternatives/your views. Cheers.

INTRO
- An idea in isolation may say little. But many ideas en masse may say a lot.

STYLE (READABILITY/MAINTAINABILITY)
- Consistent style, whatever the style is. (Develop your own style for your own code. Maintain someone else's style for a group project.)
- Use comments. (Especially for code that you use rarely e.g. once a quarter. Especially for anything that gave you a surprise/took a while to debug while coding.)
- Use a consistent style of indentation. (Note: in my view Allman style indentation is clearer than K&R style/one true brace style.)
- Text barriers between sections of code e.g. '=========='. (I use 3/5/10/15/20/30/50 equals signs.)
- Brevity is generally good, but not if it reduces clarity. (It may be better to avoid succinct but cryptic code.)
- Use a consistent case for variable/functions/method names. (In some languages you have to.)
- (All of the above points make it easier to maintain a script, or decipher a script you've never seen before.)

STYLE (SYSTEMS/ORGANISATION)
- I tend to have a system/set of rules for everything. When I'm unsure of how to present something, I follow the system. If the system doesn't have a rule for something, I reflect on what the rule should be. If I disagree with something in the system, I change it. (E.g. one minor change was changing the variable names 'vPrefix'/'vSuffix' to 'vPfx'/'vSfx', I replaced these in every script.) (One question was: I use 'o' for objects, 'v' for other variables, but what if a function parameter could be either of the two: I call it 'v', and do IsObject(), and create a new 'o' variable if necessary, that way round because there's less overhead to create a 2nd object reference versus copying the contents of a string.)
- I tend to split comments/log info/files with one file/folder per month/year.

STYLE (VARIABLE NAMES)
- I do the following, but they are just suggestions.
- Prefixes: variables v. functions. A clear distinction between variable names and function names, e.g. use prefixes for both, or end variable names with digits. E.g. vMyVar / my_var / var1, MyFunc. (E.g. outside of AutoHotkey, variables and functions can have the appearance 'XXX(Param1)', so being able to distinguish between variables/functions can be useful.)
- Prefixes: type. Prefixes to indicate a variable's type, e.g. similar to Hungarian notation, but not necessarily the same. E.g. in AutoHotkey I use 'vCamelCase' for strings/numbers and 'oCamelCase' for objects.
- Prefixes: global. Use a prefix to indicate any global variables. E.g. 'g_'. I use 'vGbl', or 'AX_' to mimic AutoHotkey's 'A_'.
- Use meaningful variable names e.g. 'path' v. 'p'.
- Collect a list of common variable names. Having such a list makes my code more reusable (you can just copy and paste blocks of code), and reduces the amount of time spent on choosing variable names.

Some example variable names:

Code: Select all

oAcc,oDict,oWB,oXl [for specific object types]
oArray,oChild,oElt,oElts,oFunc,oTemp
vChrSize,vWA
vCol,vRow
vColBGR,vColRGB
vCtlClass,vCtlClassNN,vCtlExStyle,vCtlStyle
vCtlX,vCtlY,vCtlW,vCtlH,vCtlR,vCtlB
vCurX,vCurY
vDate,vDateC,vDateM
vDelim,vSep
vDHW,vSCS,vTMM [A_DetectHiddenWindows/A_StringCaseSense/A_TitleMatchMode]
vDuration,vElapsed
vEltClass,vEltTag
vLimW,vLimH
vMax,vMin
vPath,vName,vDir,vExt,vNameNoExt,vDrive
vPfx,vSfx
vPID,vPName,vPPath,vPVersion
vText,vTemp,vInput,vOutput
vTitle,vUrl
vWinClass,vWinExStyle,vWinStyle,vWinTitle
vWinX,vWinY,vWinW,vWinH,vWinR,vWinB
vYear,vMonth,vDay,vHour,vMin,vSec,vMSec [also: vNow,vToday,vWDay]
vAddr
vAttrib [file attributes, see FileExist function]
vCaseSen
vCount
vData
vDelay
vDoRecurse [and 'vDoXXX' generally]
vDQ [double quote]
vDummy
vEnc [encoding]
vIndex
vIsMatch [and 'vIsXXX' generally]
vIsReady
vItem
vLen
vList
vLog
vNeedle
vNum
vOcc [occurrence]
vOffset
vOpt [options]
vPos [position]
vPrompt
vRegKey
vRet [return value]
vType
vUnused
STYLE (SIMPLICITY/PARSABILITY/EDITORS)
- Prefixes. By using variable/function names with prefixes it makes it easier to rename variables and collect information. (Using prefixes makes it easy to text replace and grab things without replacing/grabbing the wrong thing.)
- Comment blocks. I prefer to start every line with a comment character, over using a comment block, e.g. it's easier to parse, and if you grabbed the line in isolation you'd know it was a comment.
- Autocomplete drop-down lists. These can be useful, however, using hotstrings can be faster (for words/lines of code), and can work consistently across multiple editors.
- Syntax highlighting. This can be useful, however, it is worth considering how readable code is when syntax highlighting is not available. E.g. choices for function/variable names can aid readability.
- Editors/IDEs. It's good if you can code without too many knickknacks to assist you. I use basic editors, but a lot of hotstrings/text functions written in AHK.

STYLE (COMPATIBILITY/TRANSLATABILITY)
- Consider avoiding syntax that is unique to a language. Write in a way that is more readily translatable.
- Consider compatibility. Forwards/backwards/two-way compatibility. Write in a forwards compatible way. (Where two forwards compatible alternatives are available, consider using the more backwards compatible way. E.g. in AutoHotkey use the Length method rather than the Count method.)
- Write in the same style in all programming languages. If you want to take advantage of a rare technique in a specific programming language (e.g. for performance gains), wrap that technique in a function.

DOCUMENTATION
- Test something even if the documentation description seems obvious, or the task simple.
- It's hard to make any statement in IT that doesn't have caveats/exceptions.
- If the behaviour of something is unclear, the reader will infer their own assumptions/expectations.

ATTRIBUTION/REFERENCES
- Constants. State the names/values for all of the constants that you use. E.g. WM_COMMAND := 0x111. These are useful for debugging and as Internet search terms. Winapi constants that I can't find online I usually find in .h files that came with Visual Studio, within C:\Program Files (x86).
- Modifications. If you copy and modify someone else's code, state with a comment that you've modified it.
- Links. Consider adding Internet links to code e.g. for lists/discussions/source code/Winapi functions without standard individual MSDN pages e.g. Gdip/msvcrt/undocumented functions. I usually omit links to Winapi functions that have a standard MSDN page.
- Keep a record of links, they are gold. Keep text files with webpage titles/urls. (I have AutoHotkey scripts to copy Internet Explorer titles/urls to the clipboard, and append them to a text file. I backup my AutoHotkey forum posts for text searching. I use Bing to search for obscure AutoHotkey posts.)

FUNCTION DESIGN (WRITING FUNCTIONS)
- Function names. Some patterns that I use:
ItemOperationProperty(Item, ...) [sometimes UtilityItemOperationProperty if I'm adding functionality to an external process]
E.g. Is/Get: ItemIsProperty(Item)/ItemGetProperty(Item)
E.g. Set: ItemSetProperty(Item, NewValue)
E.g. EditGetText/EditSetText (Edit control get/set text).
- Parameter order. I use consistent first parameters based on a function's name, ProcessXXX(PID, ...), WinXXX(hWnd, ...), CtlXXX(hCtl, ...). There can be exceptions sometimes.
- The principle of least astonishment. Consider any assumptions that people would make about functionality. It's good to either meet those assumptions, or warn that you've made a different choice.
- Small general functions over big specific functions. You might want to write a function for a very specific task. However, it can be better to consider splitting it up into functions that are more widely reusable. There can be exceptions.
- Function candidates. Regular three-liners are candidates for functions, even two-liners. If you use a small amount of code three times or more, consider making it a function. You could possibly just use hotstrings for this.
- Function candidates. Avoid writing complicated code twice. If you use a big amount of similar code twice or more, consider making it a function.
- Function candidates. Wish-list functions. If you wished that a certain function already existed, or were surprised that it didn't already exist, consider making it a function.
- Write two versions of a function. A less-readable higher-performance function, and a more-readable lower-performance function. The simpler function can be used to test the more complex function.
- Medium-length function names. Use function/method names that are neither cryptically short nor unnecessarily long. E.g. too long: lastIndexOf/toUnsignedString/equalsIgnoreCase. E.g. too short: stoi.
- Global variables. Functions could use global variables for defaults, but ideally you'd be able to override those defaults by specifying a parameter, and not be required to temporarily edit any global variables. E.g. in AHK: A_DetectHiddenWindows/A_StringCaseSense/A_TitleMatchMode.
- Letters v. numbers. It's better to use letters for options, they are more memorable, cf. numbers that have no meaning. E.g. AutoHotkey's Loop File: 0/1/2 v. F/FD/D. You could also use powers of 2 (including 2**0=1) with friendly constant names, that can be combined using bitwise-or.
- Comments/examples. For any function, consider adding comments regarding what is expected for each parameter/the return value, and consider adding a one-line example showing how to call the function. The example can be useful to demonstrate typical parameter values and a suggested variable name for the return value. Without the example, the function could be quite opaque.
- Hide away low-level functionality. Ideally, in my AHK scripts, DllCall/NumGet/NumPut shouldn't be visible, such code should be inside a function.
- Pseudo-multithreading. If a task in my main script takes too long, I make it into a function, and run it as a separate script. You can achieve multithreading by using RunWait, or checking if various process exists, or communicating between scripts via messages/ini files or some other intermediary.

Some further more specific points:
Thoughts on AutoHotkey - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=17&t=42566
parameter order - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=45023

GENERAL PROGRAMMING/IT
- Backup. E.g. I have a script that copies just a small number of important files (modified since the last backup) to a folder.
- Handles. Check that you deleted the handle. Close what you opened. Avoid leaks.
- Recursive functions. Recursive functions exist, but generally I don't use them.
- Unused characters. When dealing with delimiter-separated strings it can be useful to identify/keep track of a character not present in the string.
- Loops: first/last items. The first and last item often need special handling. Sometimes you can simplify the logic by adding a last item as a dummy item. See also: the 'off-by-one error'. E.g. checking for consecutive duplicate lines, you check the current line against the previous line, but for the first line, there is no previous line.
- Loops: unused characters. When comparing items, you can use unused characters/strings that will definitely not match items in the list.
- Combining date variables is unreliable. E.g. A_YYYY A_MM on New Year's Eve/Day could return January with the incorrect (previous) year. E.g. the month variable updated, but not the year variable.

PERFORMANCE
- Machine code functions can be useful for bit/byte manipulation, that would otherwise be slow in the target language.
- Some functions open and close access to something each time. Things can be faster when you dictate the opening and closing.
- Benchmark tests. Compare the speed of two approaches, by doing them multiple times (e.g. thousands) and comparing the durations.

DEVELOPMENT (SPEED)
- Use hotstrings (text expansion) for variable names, lines of code and blocks of code.

DEVELOPMENT (FEATURES/UPDATES)
- I often write some basic code, then improve it, then improve it again etc. (The same applies to comments.)
- Acquire as many wish-list request ideas as possible before beginning a project. It can be easier to add in more functionality at a later date, if you had anticipated it, writing your code in a flexible/adaptable way.
- ... Although: use software, and you get more ideas. Often it's evolution, one idea leads to another.
- No update is better than a bad update.
- Adding self-contained features (e.g. functions/A_ variables in AHK) is usually easy.
- Changing the syntax/parser can lead to bugs.
- GitHub exists, but I don't currently use it much.

DEVELOPMENT (TESTS)
- Tests. Creating/running tests is the solution. I avoid using updated software until people have had time to test it.
- Test code. Write test code to confirm that your code/functions work as stated. Do this.
- Small-scale tests. Test the system on a small amount of dummy data.
- Test before sharing. Test your script before sharing it with others, even the simplest script, this will save you time by avoiding a prolonged back-and-forth.

DEVELOPMENT (DEBUGGING)
- To-do list. I use the label '[CHECK]' for code I want to double-check. I often write a to-do list at the top.
- Compare versions. Use WinMerge (or equivalent) to compare code, before/after.
- Website updates. When working on websites, try the website on different browsers/on a mobile phone. Note: websites can be slow to update on Chrome.
- Use MsgBox to preview things. MsgBox paths/targets/urls/JSON before doing the first FileMove/Run/download/API call etc.
- Hidden characters. You can use Ord to help identify hidden/problem characters e.g. zero-width space, see the 'characters that look similar' list:
jeeswg's characters tutorial - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=7&t=26486
- Fixed-width fonts. Using a fixed-width font, e.g. Courier New, gives each character the same width, which can be useful sometimes.
- In AHK, I turn on #Warn, and use MsgBox/SoundBeep/FileAppend/ListVars/ToolTip/the special Clipboard variable. I also use a custom function to print to console.

PROCRASTINATION
- Create a to-do list. Break things down into subpoints. Some small/research tasks, e.g. writing pseudocode, can be useful/important to do and yet easy wins.
- I view projects as taking a finite or an unknown amount of time. Either I have all of the skills already or some research will be required.
- Sometimes you can do more by switching between projects. As lethargy sets in, you can move to a different project.
- Doing multiple projects at the same time can be useful, because something in one project may be relevant to another project.
- Grouping a to-do list. Sometimes I group somewhat-related items together or organise items in a chain, where vaguely related things lead into one another in a satisfying way.

LANGUAGE DESIGN
- Some programmers have good taste. Good taste is everything.
- If you want a good language, consider writing a language aimed at beginners. This is necessary but not sufficient. (E.g. the following have some good features: AutoHotkey, BASIC, Excel functions/macros, Python.)
- Use 0-based/1-based indexes for whatever's more intuitive. Note: 0 is useful as a not found indicator. Use 1-based indexes for character positions (the nth character in a string, e.g. finding a needle string in a haystack) and the nth item in a linear array. 0-based indexes can be good for character selection e.g. EM_GETSEL (e.g. to specify selections starting before/after characters, not just which characters are selected, i.e. sections v. posts), and offsets in binary structs (e.g. and offsets in binary structs (e.g. this slice of data starts 4 bytes after the beginning of the variable).
- It can be easy to add in new functions to a language, any bugs exist only within the functions, but adding new syntax features is more complicated and risks introducing all manner of bugs.
- Ideally a language should be easy to parse.
- Ideally a language has a simple syntax, with reasonably short memorable built-in function names. (E.g. it is better for a language to not be too dependent on autocomplete drop-down lists.)
- Different syntax choices can increase/decrease readability. (Also, consider how readable code is when syntax highlighting is not available.)

LEARNING (AUTOHOTKEY)
- When I want to understand something in IT I normally try to write a simple 'hello world' script for it and then try playing about with it.
- E.g. for AutoHotkey:
- Can I get a script to send a click at regular intervals.
- Can I get the script to start/stop via a physical keypress/key combination.
- Can I write to a text file.
- Can I identify in some way what the current window is.
- Can I get text from the clipboard.
- Can I get the current date.
- And then ... let's have a look through the documentation's index.

LEARNING/DIFFICULTY
- Learn by searching. You can learn a lot by typing things into search engines. By aggressively googling. E.g. multiple keywords, error message text.
- Measure. RegEx is handy as a universal measure of a good programmer.
- Sources. With 2 sources for the same thing, I feel more sure of what the situation is.
- Learn one language, learn them all.
- Types. You could learn a language like AutoHotkey or Python, get good at it, and then move on to C++ quite easily. The one major difference is that with C++ you have to be more specific about string/number/object types, which can potentially clutter code and detract from the real code.
- 10% of core features in a programming language will be needlessly difficult to work with. Often I will write custom functions for such situations.
- 'Toy' languages. I don't see any particular dividing line between scripting or programming languages, between Excel VBA, Python and C/C++, it's all programming.
- Core concepts. When learning a new programming language, I start with strings/maths/dates/objects functionality, and also try to interact with the Winapi. Programming languages are basically: assignments e.g. var := 3, if statements, loops and functions.
- Learn by doing. Sporadic then systematic. I think it's a good approach to learn sporadically/haphazardly, to learn it when you need it, and then to learn systematically, to fill in the gaps and increase your overall understanding.
- GUIs. I was used to programming in terms of: perform these actions in this order. I was unsure of how GUIs would work, and what system I would prefer. For me, it turns out that writing lines of code to create GUIs is more intuitive and simple than trying to program 'visually' by clicking on things etc. So, I write a few lines of code to create the windows/controls, and I create some functions/subroutines that handle certain events (e.g. handle a control being clicked on, or the enter key being pressed), and that's it.

SAFETY
- Better safe than sorry.
- E.g. when writing demo scripts, only set an Edit control's text if it's empty.
- E.g. create/write to a file that is unlikely to already exist e.g. use the current date/time in the file name, yyyyMMddHHmmss.
- E.g. if creating multiple files, place them in a new folder, instead of the folder that contains the script.
- When testing forum scripts, check for commands such as FileAppend/FileDelete/FileOpen/Run.

THE GOLDEN RULE
- Avoid maintaining two versions of the same thing.
- (A caveat is to make the two versions increasingly comprised of identical components.)
- (Sometimes it's better to start again from scratch, rather than try to amend something.)

THE GOLDEN RULE OF OOP (A PERSONAL VIEW)
- Don't use OOP. Keep functions and data separate. Store information in linear/associative arrays or structs. Apply functions to those arrays.
- (While OOP is not automatically a negative, it generally overcomplicates things. It is overused and misused.)

CULTURE PROBLEMS (A PERSONAL VIEW)
- We have culture problems: OOP, the Ribbon, appearance over performance, OSes lacking in customisability.
- Also, there are too many programming languages/web frameworks/content management systems/Linux distros.
- Also, another problem: creating a new programming language when we should have created new functions/a new function library.

AUTOHOTKEY-FRIENDLY/HARDWARE
- If you're writing a program or operating system, make it automation-friendly. E.g. support multiple WM_COMMAND or WM_USER or other messages.
- If you're creating a computer keyboard, make it AutoHotkey-friendly. E.g. make it so that the Fn key can be detected in AutoHotkey's KeyHistory.

==================================================

QUOTES

UPDATES
[C++: small updates]
Oral History of Bjarne Stroustrup - YouTube
https://www.youtube.com/watch?v=ZO0PXYMVGSU
[01:12:40]
some of the things people are most excited about [about] C++11,
actually, [are] not the advanced features, [they're] some of the simplifying features

SYNTAX
[Python: Python redone would use curly braces]
Oral History of Guido van Rossum, part 1 - YouTube
https://www.youtube.com/watch?v=Pzkdci2HDpU
[01:51:07]
if I were to design a new language today ...,
if I would use indentation ...,
every other language ..., all curly braces-based

==================================================

LINKS (MULTIPLE PRINCIPLES):
Zen of Python - Wikipedia
https://en.wikipedia.org/wiki/Zen_of_Python
PEP 20 -- The Zen of Python | Python.org
https://www.python.org/dev/peps/pep-0020/
Category:Software development philosophies - Wikipedia
https://en.wikipedia.org/wiki/Category:Software_development_philosophies
List of software development philosophies - Wikipedia
https://en.wikipedia.org/wiki/List_of_software_development_philosophies
Computer Programming Principles - Wikibooks, open books for an open world
https://en.wikibooks.org/wiki/Computer_Programming_Principles

LINKS (INDIVIDUAL PRINCIPLES):
Principle of least astonishment - Wikipedia
https://en.wikipedia.org/wiki/Principle_of_least_astonishment
['If it ain't broke, don't fix it.']
Bert Lance - Wikipedia
https://en.wikipedia.org/wiki/Bert_Lance#If_it_ain't_broke,_don't_fix_it
[my paraphrase: 20% of the people produce 80% of the stuff]
Pareto principle - Wikipedia
https://en.wikipedia.org/wiki/Pareto_principle
Don't repeat yourself - Wikipedia
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
[off-by-one e.g. sections v. posts]
Off-by-one error - Wikipedia
https://en.wikipedia.org/wiki/Off-by-one_error
Not invented here - Wikipedia
https://en.wikipedia.org/wiki/Not_invented_here
Order of operations - Wikipedia
https://en.wikipedia.org/wiki/Order_of_operations

LINKS (INDIVIDUAL PRINCIPLES) (FURTHER):
KISS principle - Wikipedia
https://en.wikipedia.org/wiki/KISS_principle
Necessity and sufficiency - Wikipedia
https://en.wikipedia.org/wiki/Necessity_and_sufficiency
Feature creep - Wikipedia
https://en.wikipedia.org/wiki/Feature_creep
[YAGNI]
You aren't gonna need it - Wikipedia
https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

LINKS (ETIQUETTE):
[As an answerer, I will…]
Stack Overflow Culture | Jon Skeet's coding blog
https://codeblog.jonskeet.uk/2018/03/17/stack-overflow-culture/

LINKS (TIME):
Hofstadter's law - Wikipedia
https://en.wikipedia.org/wiki/Hofstadter%27s_law
Ninety-ninety rule - Wikipedia
https://en.wikipedia.org/wiki/Ninety-ninety_rule

LINKS (AUTOHOTKEY FORUM):
your personal AutoHotkey style guide - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=17&t=47140
which languages should I learn to learn DllCall and Windows API Functions? - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=59780
Thoughts on AutoHotkey - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=17&t=42566
parameter order - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=45023
Debugging tutorials - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=62528

==================================================
Last edited by jeeswg on 12 Mar 2019, 10:35, edited 4 times in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4466
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: principles of programming

05 Jan 2019, 19:48

You make some decent point at times - at other times it makes me shake my head.
"We don't need highlighting/autocomplete because it slows you down"
A funny joke you made there - High quality Syntax Highlighting and a powerful editor are the foundation of good development.
In my eyes it seems like you lack a good one. (Seeing that you use Notepad++ just confirmed it).
You then proceed to suggest keeping a Hotstring list of common variable names that you use.
After you rejected auto-completion from the Editor side - this whole thing looks ridicolous.

You suggest keeping backups and suggest using a tool to find the differences between several files.
Doing both with git would allow you to do both more easily.

Consistent first parameters based on a function's name, ProcessXXX(PID, ...), WinXXX(hWnd, ...), CtlXXX(hCtl, ...).
These would be prime examples of something that should be turned into an object.

Generally you make points against OOP - they are not necessarily wrong.
When I say that functions are overused, misused, inconsistent, often of very very low quality and mostly only fit one specific situation then I would not be wrong either.
I say use functions and use objects where they belong.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: principles of programming

05 Jan 2019, 20:58

HIGHLIGHTING/AUTOCOMPLETE, ERRORS, EDITORS
- Hello nnnik. In theory custom/built-in autocomplete drop-down lists could be useful, and I've experimented with them, but I've always found hotstrings easier/faster.
- I've tried syntax highlighting, but I've never found it particularly helpful, and I've never missed it when it wasn't there. I suppose my variable/function naming system and use of hotstrings for common code lines/blocks makes it less needed.
- One use of syntax highlighting is to know that certain structs are defined, e.g. in Visual Studio. I.e. that you've done the necessary includes (imports).
- One thing I do like about good IDEs is highlighting any errors, or reporting information about errors.
- I like using Notepad/Notepad2 (with extra features via AHK). Other editors I've used: Visual Studio/NetBeans (Java)/IDLE (Python)/Notepad++. (I've written some code to add consistency across editors, I might post it.)
- For editing the AHK source code, I like to edit the files in Notepad2, and then compile using Visual Studio.

- I've updated the highlighting/autocomplete point. Actually, it was inspired by you, when you seemed to me surprisingly sure of autocomplete's necessity, although yes both can be useful.

Code: Select all

;before:
- Highlighting/autocomplete. You're better off not needing these as they slow you down. Hotstrings can be useful here. (You want a system that works well in Notepad. I.e. in any code editor.) (Ideally a language has a simple syntax, with short memorable built-in function names.)

;after (the 'Ideally...' line was moved to LANGUAGE DESIGN)
- Highlighting/autocomplete. These can be useful, however, using hotstrings can be faster (for words/lines of code), and can work consistently across multiple editors.
EDITORS
- I find it fine to program with zero IDE support/fancy features, and I think it can be a good experience to try programming in Notepad, and develop the hotstrings / additional features to make it a viable option. (One little example, I added Ctrl+D to duplicate the line above.)
- Two handy features that Notepad lacks:
- I like editors that can state the line numbers, which is especially useful if word wrap is on. Scintilla controls can do this (e.g. Notepad2/Notepad++).
- I like editors that remember your 'column' position. As you scroll down lines, the caret moves leftwards where necessary (to the end of short lines), and returns rightwards to the original column where possible (for longer lines). On Edit controls, it forgets the position, moving ever leftwards. Hmm, I meant to try implementing this in Notepad (and Edit controls generally).
- I find it funny when 'multiple cursors' functionality is celebrated, although it does look cool. It goes against the DRY principle.

GIT
- Re. Git. I've found using WinMerge to always be sufficient.
- I would explore it further, if I thought it might be beneficial.
- Do you have any sort of Git system for use on your PC? Or do you just use GitHub online.

FUNCTIONS, OBJECTS, BIG PROJECTS
- Re. 'These would be prime examples of something that should be turned into an object.'
- I think that the example could work fine as an object or as functions. One point is simply: would objects have a greater overhead.
- Perhaps it's simpler to implement a small function across multiple programming languages than to implement a class.
- Furthermore, you might not have the time or desire to implement all of the methods for one class in another programming language. And you might add new methods to your class in one programming language, but not the other. So, the small functions could likely be written once only and be done with, whereas the classes could be in various states of incompleteness across different programming languages.

- I feel pretty neutral on functions, objects etc.
- I wouldn't mind someone giving a really good summary of design patterns. To try and compress their experiences into a few-page document.
- Re. OOP, I would welcome any information to be added here:
OOP: resources - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 17&t=51599
- I would love to see something like 'principles of programming *for large projects*' for software/websites/servers/apps.
- From reading/watching videos, I tend to hear: keep everything as lightweight/simple as possible, to reduce processing/storage requirements. I.e. the bigger the project, the more you benefit from simplicity.

- You've mentioned highlighting/autocomplete/OOP. Any other points to highlight that you liked/disliked? Cheers.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4466
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: principles of programming

06 Jan 2019, 05:03

I use: https://git-scm.com/book/en/v2/Appendix ... Powershell
So when I browse my folders with Windows Explorer I can open Powershell directly with a menu - if Im in a folder which contains a git repository I immediately get some information about the projects status.

My workflow normally goes among the likes of:
I start a new project - when I see it does something useful I upload my files to github.
"git clone" then copies the repositries files into a local repository - (I do that because its easier than manual linking and I normally get a better name during development).
After making some changes I call "git diff" or "git stats" to see which changes I have made.
If I checked everything is correct and like it I add all the files to gits tracking mechanism ("git add *" in the repositories folder).
Next I create a commit with "git commit -m "comment"" and push the changes online "git push".

Whats also incredibly useful is when you work with multiple people on one project is feature branching.
First your group will come together and start discussing the new features and will assign them.
Then each developer will modify the current codebase to include their own works.
Then they are going to push the feature that they added into the repository - but on a seperate branch (essentially a seperate version).
You can create this new branch after you added the code or before you add it. The command is git checkout -b feature_branch_name where feature_branch_name is replaced by the name of your feature.
After a fixed amount of time the team will meet up again and they will inspect the results of their work.
For that they just need to check each of the branches individually.
Finally the branches are merged together by using "git merge feature_branch_name" on all of the feature branches.
At which point there is one central state the repository is in and the cycle begins anew.
If you have a good git environment you can probably also work with merge requests to make the whole process more dynamic.


I use multiple input cursors in AHK Studio. AHK Studio has a quick search feature which highlights every instance of a found string.
When leaving there is a multi cursor at every position. This makes renaming thins so easy.
You can do the same in AHK studio by selecting a string and then clicking on the similar instances of text it finds.
Highlighting provides simple visual information about code structure and makes traversing the code structure easier for the eye.
If I had to guess - your preference of short simple lines in programming comes from this.
Actually I think a lot of your style comes from this decision - like how you name variables or keep everything prefixed to work with it or how you seperate everything with ====.
Most people will tell you though that just using Syntax Highlighting is a lot easier to use/get used to.


I'm really tired of discussing OOP with you. What its good for and not is something you have to decide when you learn it in full.
One thing classes would be useful for is Send sequences. Send methods are often switched out for one another yet AutoHotkey asks you to define those when sending keypresses to a window.
AutoHotkey already has a method to change the send method without changing the command you wrote.
That is SendMode in combination with a normal Send. However this pollutes global scope.
During this process the active window might even change and AHK will send to a completely unrelated window because it does not detect this.
It would be better if we made people use a pattern like this:

Code: Select all

spotify := WindowSender("ahk_exe Spotify")
sendData(spotify)
sendData(spotify) {
	spotify.send("Some keys")
	spotify.send("More keys")
}
The sendData function would always remain the same - however when you change what you pass to it as object you can completely change the way that it works.
Perhaps you want to replace SendInput with ControlSend to work in the background - perhaps you want to use some fancy API instead.
the options are not limited - you just need to pass an object which implements the send method.
Recommends AHK Studio

Return to “Offtopic”

Who is online

Users browsing this forum: Bing [Bot], Joe Glines and 6 guests