AutoHotkey Community

Yes, it asks for a file and a directory: two different things, thus the code must differentiate between the two, which the current AHK example does not. I've noticed that many (most?) of the rosetta code tasks are poorly worded; but this sentence is unambiguous:It does not ask to verify that a "file or directory" called input.txt exists; it asks for a file. Unfortunately, coding this in AHK requires multiple steps.

some other examples don´t differentiate either, e.g. http://rosettacode.org/wiki/File_Exists#DOS_Batch_File
So i´m not shure if it´s really demanded, but
if you exchange the example, please replace the ternary operators by full blown if-clauses. It will be much more understandable that way.

Laszlo noted that most of the 99 bottles of beer examples are wrong also. I'm sure Rosetta code doesn't have the manpower to validate all the code examples (or even a fraction of them). Also, part of the site's purpose is to see how different languages attempt to solve a task, even if that task can't be solved in a given language.

So my question is more philosophical. Is it better to show a readable example in the spirit of the task, even if that example doesn’t meet all requirements, or should the problem be explicitly solved, even if it requires longer, less-readable code to fulfill every detail?

Right now, I’m leaning towards solving the problems in detail. If we assume the details are there for a reason (not necessarily true) and if AHK can fulfill the details, I see more value in being sticklers… but I’m open to other ideas.

Eek. Was mine incorrect also? I was sure I tested it to work correctly.

_________________

Try Quick Search for Autohotkey or see the tutorial for newbies.

After rereading the task, i lost my doubts, the Batch- and the AHK-example are both wrong. So at least the ahk-version should be exchanged.

IMHO we should explicitly solve all given tasks and meet all requirements we can.
it is probably neither good for rosetta nor for ahk if we show only the "good" sides of the programming language.
especially if we skip requirements for better readability, people might get the impression, that certain tasks are not doable, when they are in fact only a little bit more complex.

maybe this is more readable and still correct?

That code looks good to me. I've posted it on Rosetta with a note about the FileExist() function.

@sinkfaze
I didn't test your example for accuracy. I think Laszlo's main complaint was readability.

<pontificating>
Given the choice between two accurate alternatives, I like to post examples that play to AHK's strengths. For GUI creation, AHK has other languages over a barrel; so I like to show examples of simple little GUIs. Also, I believe other languages use the command line to display (or "print") text because that's the easiest method for them. No one does this with AHK. The most common way we display text is with MsgBox, followed by custom GUIs. I think we should try to show examples that portray how AHK would actually be used to complete tasks.

I’m indecisive about posting code for many of the tasks, because I try to juggle several priorities.

1. Accurate – is every detail of the task completed?
2. Readable – is the code unnecessarily concise?
3. Representative – does the code portray typical usage?

Whenever possible, AHK examples should meet all three of these ideals; otherwise I try to accomplish them in order.
</pontificating>

Well on that note, here's an AHK solution for Divide By Zero Detection that can be checked for optimization, although I'm not sure how you quantify their requirements (not checking the denominator for a zero, is detection required before or after the process is complete, etc):

_________________

Try Quick Search for Autohotkey or see the tutorial for newbies.

I think checking the output as you've shown is the best AHK can do. A more concise example is ... but is that "unnecessarily concise?" Here's where I'm indecisive.

P.S. Shouldn't 0/0 be a valid operation?

You have to check for an empty string not just a false value, to make sure a zero numerator does not give a warning.

You don't have to worry about optimizing these silly examples.

I wouldn't worry about 0/0 too much...
Unless you want to get into field theory

Another version of bubblesort here

I was just throwing the code together to get an answer but after seeing tinku99 wrap the code into functions for many of these answers I'm becoming partial to that idea since a potential tester can enter their own values into the function call to confirm it works. Particularly in the case of something like dividing by zero, where a zero in the numerator can be tested to ensure that it does not error the same way that a zero in the denominator does.

_________________

Try Quick Search for Autohotkey or see the tutorial for newbies.

Strictly speaking, the ZeroDiv function above is still incorrect: if num1 or num2 is non-numeric, the result of the division is still empty, but there was no division by zero. You just have to check if num2=0.

The task explicitly forbids this.

I see. But this task makes no sense, since most interpreted languages check the divisor internally, anyway. If you still want to play along, first you have to check num1 and num2 “if var is number”.

I had initially created a separate thread for this, but in the interest of not cluttering the forum, will delete that other thread.

I added a category on rosettacode for tasks that seem so obvious to me as an autohotkey user, but aren't traditionally supported well in programming languages: AutoHotkey_Originated.
It was also a good way of keep track of what we add, besides translating the tasks already on rosettacode.
Consider posting any new tasks here, before posting on the wiki.
If you do add a task, use this wiki template: