Source Viewer: A word indexer for text files

Post Reply
User avatar
Cedron
Posts: 118
Joined: Thursday 21st February 2019 5:02pm
Location: The Mitten State
Contact:

Source Viewer: A word indexer for text files

Post by Cedron » Monday 08th June 2020 10:10pm

Original version:
SourceViewer-0.0.3.tar.gz
(17.58 KiB) Downloaded 12 times
Improved version:
SourceViewer-0.0.7.tar.gz
(19.75 KiB) Downloaded 6 times
So I'm working on a large project, several coordinated pieces via TCP, using several C++ IDE instances across different subdirectories in the same directory.

Finding stuff is somewhat cumbersome, for me at least, within and across these IDEs. This project is a solution. Consider it a celebration of the GridView control.

The ToolTips on most the controls should be enough to explain their function. A little playing around will solve the rest. If the ToolTips annoy you then double click on the current folder label and they will be destroyed until the next time the program is run.

There is still some quirky behavior that I am not bothering chasing down. I also learned some things:

1. A TextArea may not give back the same text it was given, a TextEditor does.

2. The TextEditor (and Gambas IDE) displays and counts an extra line at the bottom that isn't really in the file.

I hope you all find it useful. I will be upgrading my version with functionality specific to my coding style which I will share privately upon request.
Last edited by Cedron on Friday 19th June 2020 11:02pm, edited 1 time in total.
.... and carry a big stick!

PJBlack
Posts: 3
Joined: Tuesday 09th June 2020 10:26pm

Re: Source Viewer: A word indexer for text files

Post by PJBlack » Tuesday 09th June 2020 10:30pm

wow ... nice work ... thanks for that one :)

User avatar
Cedron
Posts: 118
Joined: Thursday 21st February 2019 5:02pm
Location: The Mitten State
Contact:

Re: Source Viewer: A word indexer for text files

Post by Cedron » Thursday 18th June 2020 8:08pm

SourceViewer-0.0.7.tar.gz
(19.75 KiB) Downloaded 23 times
Hi PJ,

I truly appreciate that you signed up so that you could log in for that comment. Thank you.

Attached is an improved version with more functionality and resizability. It works particularly well on Gambas source code trees.

Ced
.... and carry a big stick!

PJBlack
Posts: 3
Joined: Tuesday 09th June 2020 10:26pm

Re: Source Viewer: A word indexer for text files

Post by PJBlack » Thursday 18th June 2020 10:00pm

Hi Ced,

i "know" you from the gambas mailing list and i am a fan of your coding, even i did not agree with you in particular points (eg naming conventions) ... but thats my problem not yours ;)

The actual version is a big improvement in user interface and it's still awesome !

As usual your code is a pretty good lesson in programming and working with gambas, thanks again for that!

PJ

User avatar
Cedron
Posts: 118
Joined: Thursday 21st February 2019 5:02pm
Location: The Mitten State
Contact:

Re: Source Viewer: A word indexer for text files

Post by Cedron » Friday 19th June 2020 2:57pm

Thanks again for the kind words.

Coding style has four principal elements:

1. Formatting conventions
2. Naming conventions
3. Commenting
4. Organizational preferences

From previous discussions on the mailing list, I know not everybody is fond of my coding style, and the naming conventions seem to be the most disagreeable. After 40+ years of programming, you might wonder why somebody finds it really useful to use readable explicit names that can be traced across many files with prefixing the lets you know at a glance where the variable was defined.

Curse Hungarian prefixing, it sucks. Ugliest code recipe ever. The type is a lot more discernible from context than the locus (where it is defined), so less utilitarian as well.

Some people prefer cryptic variables names. I understand that. I use them also for local variables where the definition is never far away.

If you're up for a challenge, I would recommend adding a button on the upper right which reads the word list and generates a text file with two columns. The first is every variable name instance you find with my naming convention. The second is an automatically name mangled cryptic version derived by some rule from the first. Then add a second button which reads this file, then loops through all the files, and for every occurrence of a variable name instance, replaces it with the new alternative.

This will let you push the first button, edit the text file for tweaking, apply the name changes. Done properly, it should be "provably correct" so you won't introduce any bugs.

One rule might be to scan the variable name for capital letters, convert them to lower case and make that the name. Your program needs to ensure that you don't produce the same replacement name for two different variable names. Another rule might simply be to strip the prefix. If you're a Hungarian fan, you should be able to find the variable definitions (quasi-compiling) and prepend type identifiers to the variable names. Good luck coming up with an agreeable list of prefixes for that.

If you do this, please post it as a reply as I suspect there are other people who would find that useful as well. They want to use my code, but the naming convention clashes with their coding style so ....

My prefixes are easy to spot mechanically. They are:

Code: Select all

My  = Public property
my  = Private property

Our = Static public property
our = Static private poperty

The = Form control  (externally public or not)
the = Local variable

Arg = Calling argument in public method value is read only
arg = Calling argument in private method value is read only

Ret = Calling argument in public method value is return only
ret = Calling argument in private method value is return only

Mod = Calling argument in public method value is modified
mod = Calling argument in private method value is modified
Names that are part of structs don't get prefixes. They are never used stand alone and the locus is determined by the struct.

Here is a line of code:
    TheFileGridView[r, 5].Text = Str(theFileHolder.MyLineCount)

Here's what I can tell just from the naming:

"TheFileGridView" is a GridView control on the form. "theFileHolder" is some sort of object or struct. I know it is an object because of the "My" on its member. (A "my" would be an error check in this case as it is supposed to be private and not accessible) It is either a "Holder" object for "File" instance, or it is the sole FileHolder in that routine. In this case, the latter.

Any doubt what "LineCount" means? Would "lc" be preferable? Or "nLines"?

Finally, consider if you had a verbally interactive IDE, and you want the code mechanically read to you, which naming convention do you think would work best?

Read these out loud:

"The file grid view element r comma five dot text equals string function of the file holder dot my line count."

Corresponding Hungarian:
    gvFile[r, 5].Text = Str(oFileHolder.nLines)
"g v file element r comma five dot text equals string function of o file holder dot n lines"

Readability enhance comprehensibility. The readability of something is highly dependent on the reader, so the style you are used to is the one you will find more readable. Funny how that works.
.... and carry a big stick!

Post Reply