|
There's actually a reasonable number of comments and blanks!
|
|
|
|
|
"cloc *.c"
Dear Jesus, I miss the command line. I really need to go back to Unix development. Or go on a car camping road trip alone...
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
In my last job, we needed to know the number of code / blank / comment / hash / blockdelimiter-only lines in various languages (with different comment markers and block delimiters), as well as code lines with embedded or end-of-line comments.
Coding it wasn't much above the 'trivial' level. Setting up a standard directory search dialog, a set of check boxes for file selection on type and optionally name, traversing/filtering the selected directories are straightforward, standard tasks.
Actually, my biggest problem was handling those files that were themselves processing source code: They frequently contained string values that were comment start/end, confusing the search for "real" comment markers. And nested comments were nasty. I didn't have the resources for writing full parsers for all the languages in question, so I did a few dirty shortcuts; I am not sure if nested comments always were counted 100% correctly, but the assignment called only for an 'estimate', reporting in KLOCs, not exact values, so it was 'good enough'.
The functionality went significantly beyond cloc. The tree traversal and file analysis (i.e. line counting) was somewhere around 400 lines of C# code.
So, if you really miss it badly: Sit down and code it, with a GUI interface.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
I agree. Of course, this can be done. I just miss the cleanliness of Unix as compared to the 5 headed hydra monstrosity that Windows has become. VS2022 is so bloated, we should bring back whaling and turn it into oil.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Quote: # define this not_the_cpp_this
I'm refactoring my code now to follow this pattern.
May future maintainers writhe in pain.
cheers
Chris Maunder
|
|
|
|
|
|
|
...or the similar ones that don't have a scroll thumb (just arrows), but being "nice to people", open at the default of USA.
Australian sites, for ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) sake. click, click, click, click....
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Also think about the poor Canadians
|
|
|
|
|
I want to see the data storage for this ui... Do you have to join two tables to get the full phone number. This will be a piece of code they look back on and hopefully say, what was I thinking!
Table: Address
int CountryCodeID
string PhoneNumber
Table: CountryCode
int CountryCodeID
string CountryCode
Hogan
|
|
|
|
|
PIEBALDconsult wrote: Requiring the country code seems unusual (for a site in the U.S.)
What do you mean - is there anything outside the USA? Do they have telephones as well? Really?? 
-- but what would prompt a web developer to make it an elephanting drop-down?! I guess that even a lot of Europeans do not know the phone country code of their homeland. I guess that a lot of USA citizens, if they had to call home when on a dangerous vacation trip to The Primitive World outside USA, would go straight ahead with their US number, unaware that they have to prefix it with +1. On a landline phone, that might be 001, or 0951 (that's in Norway, up until 20-30 years ago), or something else. Even when told about the '+1', many would not know the meaning of the 1, but view the whole prefix as a deficiency of the country's phone system.
So, I think this drop down list, displaying both the code, so that users learn it, and the name of the country, for those who are not sure about the code, is a really good idea. It is not possible to see from the screenshot if you are allowed to type the code directly without using the pulldown list. Users who know their country code with 110% certainty would most likely prefer that - but maybe their memory has a bit error, or they make a typing mistake, so they specify an unused code or the code of a completely different country. The pulldown list is one way for the software to ensure that a valid number is entered. And, the selected value can display the country: Users from other countries might leave a '+1' untouched without noticing. They are much more likely to notice '+1 (US)': But I am not in the US!
The UI isn't really that bad, in my eyes. I think what I saw yesterday was far worse: I sent a notice through the web pages of the Norwegian Automobile Owners Association. The form had entries for name, email, and membership number: The membership number field was a spin control starting at -1. I did not let it spin up to my number (a value for the field was not mandatory) 
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
The other day I wrote an SQL function with a bug of the following form:
DECLARE @i INTEGER = 0
WHILE ( @i < foo )
BEGIN
IF
BEGIN
SET @i = @i + 1
END
END
I expected the function to be inefficient, but not infinite the first time the test returns false. 
|
|
|
|
|
if your condition is never met (or not met "foo" times), your loop control will never increment (or not increment enough to break on the condition), thus the loop will be infinite.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I think its a bad idea. SQL is the wrong place to perform that type of logic. If you can't perform it in a set type of operation, then move it out of SQL. Working with this limitation has made my SQL skills stronger and encouraged me to think differently about modifying data.
I get that there are exceptions and if you have to do it in SQL, it already has cursors.
Hogan
|
|
|
|
|
Absolutely. I'm a huge proponent of not doing the kinds of thing I'm doing at the moment in SQL*, but I'd rather have it for when it makes some sense.
snorkie wrote: think differently about modifying data
Which isn't what I'm doing in this particular case.
snorkie wrote: it already has cursors
Certainly, but still not applicable to this particular case.
* This is just a quick-and-dirty little investigation into some data analysis. I might re-write these functions in C#, but it's really not worth the effort.
|
|
|
|
|
Disagree a bit, and do not care a lick that it defies popular wisdom.
Working with input/output as close to the source/destination tends to mean both less traffic and faster.
I feel this 'wisdom' is somewhat rooted in the same vein as folk who love NoSQL because it means they don't have to learn databases.
|
|
|
|
|
I worked at a company who preferred to do as much as possible in SQL Server.
A stored procedure, as they claimed, is easy to change in production and you can write business logic in the one place where every user action ultimately ends up in: the database.
The client applications were all WinForms.
Of course, all of this is a fallacy.
Yes, it's easy to change a view or stored procedure in production (we could make the change and hit F5), but the question is why wouldn't software be easy to update?
This was about 10 to 14 years ago, but this company did not have DevOps practices and every deployment was manual work, which also required users to restart the software (which was of course pretty common at the time).
That last part is a nuisance which really can't be helped at this point (unless you use stored procedures), but having a difficult and manual deployment process can be helped and should be helped.
Which would remove a part of the need for stored procedures and logic in your database.
The second reason, having everything in one place, can of course be solved by using services in a server-client, service-oriented and/or microservices architecture.
And when you have services doing all the logic, you don't have to restart client applications either.
Now, instead of using stored procedures and views you can use a service instead.
A service is easy to debug, easy to put in source control and easy to automatically deploy, unlike SQL code.
And you never have the risk of updating the wrong thing either (which happened from time to time) because you're simply not messing around in production environment "on the fly".
So, I've made a choice to let a database do what it does best, store data, and keep it as "dumb" as possible.
Everything else is handled by applications and services 
|
|
|
|
|
Sander Rossel wrote: easy to change in production
That's my main argument against putting code in the database.
Auditing what code is where becomes difficult. I've had to write systems for comparing procedures and functions between environments to ensure that what we thought was in production actually was.
It would also be true of other systems where you don't deploy compiled executables -- e.g. Python.
Sander Rossel wrote: a choice to let a database do what it does best, store data, and keep it as "dumb" as possible.
Totally agree.
But, I still argue for having tools. What I'm working on is just an idle curiosity.
|
|
|
|
|
PIEBALDconsult wrote: comparing procedures and functions between environments to ensure that what we thought was in production actually was.
Been there, done that 
|
|
|
|
|
Like with so much, I think it's a bit more of an "it depends".
Database engines are very good at retrieving complex indexed data structures quickly.
I don't know if there are any tests out there but I reckon for very large datasets, with multiple joins, a database engine probably still beats using something like Entity Framework - happy to be shown to be wrong on this.
So I think for small simple datasets - yes, placing all the logic inside the service probably does make sense.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Yeah, but EF can just as well generate queries and let the database handle the retrieval.
But you're right, in some cases writing a stored procedure could be more performant.
Although EF has been getting better in that regard (like there are built-in DeleteAsync and UpdateAsync methods).
|
|
|
|
|
GuyThiebaut wrote: I don't know if there are any tests out there but I reckon for very large datasets, with multiple joins, a database engine probably still beats using something like Entity Framework
Not a standard test by any means, but definitely proven in my applications where I've used stored procedures as against queries within the software.
Happiness will never come to those who fail to appreciate what they already have. -Anon
And those who were seen dancing were thought to be insane by those who could not hear the music. -Frederick Nietzsche
|
|
|
|
|
It's kind of a nasty alternative, admittedly, but I'm used to it because of a c pattern I employ all the time
while(count--) { ... }
I think because I'm so used to dealing with that I spotted your bug right away.
These days I prefer to generate SQL, DML and DDL code because it's so sloppy, like JS. Really it should be transpiled from something more modern and cohesive.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
honey the codewitch wrote: It's kind of a nasty alternative, admittedly, but I'm used to it because of a c pattern I employ all the time
C++
while(count--) { ... }
Or, for a slightly more readable (but slightly less efficient) code construct, you can use the fake 'down to' / 'tends to' operator -->. It works in C, C#, JavaScript and other C derived languages but it does not actually exist as an operator. e.g.
while (count --> 0) { ... } as it is just an unusually laid out version of
while ((count--) > 0) { ... } and the test for > 0 is redundant as when count is positive the result is already true and when 0 it is already false.
One useful feature of the --> operator is that it allows counting down to non-zero endpoints as well as just down to zero.
|
|
|
|
|
I had used Windows since 3.0 (ca 1991) before I switched to main usage of Linux in 2019 so please don't make fun of me for this too much.
I've been working on setting up my .NET Core WebAPIs (hosted under various domains but running on one copy of a DigitalOcean droplet (running Debian)) and setting up the services and forwarding via Nginx and all that. It's all command-line there are a lot of steps that I forget often.
1. set up a service file in /etc/systemd/system/
2. build the WebAPI and deploy it under a folder in /var/www/
3. configure nginx to point at your webAPI
4. create link to the nginx config ln -s /etc/nginx/sites-available/<apiName> /etc/nginx/sites-enabled/
There's a bunch of things and I would lose the commands and forget things I should do.
And, I be forever up-arrowing to get to old commands that I had used.
.bash_history
Then I stumbled upon the .bash_history file and noticed I can open it up in an editor (nano, of course, because I am vim-weak and don't know how to exit vim  )
Wow, that is really cool that all those commands are just sitting in there like that so I can now pull them out and save them to a file with some documentation.
Thank you, Linux, it seems like you get better all the time.
I bet you already knew about .bash_history didn't you? Well, try not to laugh at me too hard for only finding it now.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
