Re: [sqlite] Programming methodology (was DEF CON (wasL A license plate of NULL))
On 15 Aug 2019, at 18:13, James K. Lowden wrote: > On Tue, 13 Aug 2019 16:47:43 -0400 > Richard Hipp wrote: > >> On 8/13/19, Jose Isaias Cabrera wrote: >> > >> > I see all of you smart programmers using this >> > non-column matching behavior, and I ask myself why? >> >> Because that's the way Dennis Richie did it. :-) > > That's right. Like many of a certain age, I learned C from K, and > adopted Ritchie's style. In terms of learning C, me too. However I looked at the various styles and adopted Whitesmiths; the braces align and I'm not wasting time looking for the matching one. -- Cheers -- Tim ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Programming methodology (was DEF CON (wasL A license plate of NULL))
On Tue, 13 Aug 2019 16:47:43 -0400 Richard Hipp wrote: > On 8/13/19, Jose Isaias Cabrera wrote: > > > > I see all of you smart programmers using this > > non-column matching behavior, and I ask myself why? > > Because that's the way Dennis Richie did it. :-) That's right. Like many of a certain age, I learned C from K, and adopted Ritchie's style. I'm reminded of Bjarne Stroustrup's complaint about the C++ standardization process. He would ask those assembled to offer suggestions for how C++ could be made easier to use and more approachable for the novice. That question was always met with silence. If you want a lively discussion, he said, ask where the curly braces belong. --jkl ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Programming methodology (was DEF CON (wasL A license plate of NULL))
On 8/13/19 4:47 PM, Richard Hipp wrote: > On 8/13/19, Jose Isaias Cabrera wrote: >> I see all of you smart programmers using this >> non-column matching behavior, and I ask myself why? > Because that's the way Dennis Richie did it. :-) There are many ways to format code, and many programmers have a strong preference to the way THEY want it. In many ways this choice is a bit like religion, sometimes hard to really explain why, but often the believer has some ideas about it, and the choice is often firmly held and hard to change. I personally like the K style, as it is compact and dense, so you can see more code. Some people dislike it for much the same reason. While the braces don't align, the closing brace does align with the beginning of the statement it is closing, and there is nothing else in that column between so scanning up to find it isn't that hard (and then to the end of the line to see the opening brace). If the distance is long, I will add a comment after the closing brace describing the start statement to make it easier to match. Yes, this format makes it harder to see mismatched braces, but by compiling often you get a syntax error with miss-matched braces, and letting your editor find matching braces it tends to be fairly quick to locate it. The key is to compile (or have the editor syntax check) often enough that you can't make two opposing errors like this that hide each other. -- Richard Damon ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Programming methodology (was DEF CON (wasL A license plate of NULL))
On Aug 13, 2019, at 3:11 PM, Jose Isaias Cabrera wrote: > > Somewhere in my basement exists a book called, "The C Programming Language.” It’s worth a re-read, even if you no longer use C. You will certainly find insights that affect however you *do* program these days. The last time I dipped into my first-edition copy, I discovered that K C didn’t even have malloc()! That was considered outside the language, something to be left to the host OS’s API. Instead, the book has two code examples showing how to implement something malloc-like atop the old Unix brk(2) syscall. There is no malloc() in V6 UNIX’s libc, either. That didn’t appear until V7 UNIX, which was released about a year after the first edition of K was published. That code is a lot like the second implementation of alloc() in K, within its Appendix A. The earlier implementation of alloc() in the book was trivial: inefficient, but easy to understand. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Programming methodology (was DEF CON (wasL A license plate of NULL))
Richard Hipp, on Tuesday, August 13, 2019 04:47 PM, wrote... > > On 8/13/19, Jose Isaias Cabrera, on > > > > I see all of you smart programmers using this > > non-column matching behavior, and I ask myself why? > > Because that's the way Dennis Richie did it. :-) Somewhere in my basement exists a book called, "The C Programming Language." ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Programming methodology (was DEF CON (wasL A license plate of NULL))
On 8/13/19, Jose Isaias Cabrera wrote: > > I see all of you smart programmers using this > non-column matching behavior, and I ask myself why? Because that's the way Dennis Richie did it. :-) -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Programming methodology (was DEF CON (wasL A license plate of NULL))
On 13 Aug 2019, at 9:42pm, Don V Nielsen wrote:
> bool is_true (bool tf)
> {
>if (tf == true) return true; else return false;
> }
Do you get paid by the line of code ?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Programming methodology (was DEF CON (wasL A license plate of NULL))
If I were to have coded that junk (and I do see it too many times to
count), I would have coded it even junkier, as in
bool is_true (bool tf)
{
if (tf == true) return true; else return false;
}
If it's single statement following an if and that statement isn't beyond 80
characters, I will code it as a single line
bool is_true (bool tf)
{
if (tf == true) { return true;}
return false;
}
I would normally comment the method with something like
// SWEET MOTHER OF MOSES, WHO CODED THIS
// But since it is existing code, I have chosen not to touch it and kick
the can down the road.
// I don't want to be responsible for retesting the 97 million functions
that actually employ
// this piece of
On Tue, Aug 13, 2019 at 2:52 PM Keith Medcalf wrote:
>
> On Tuesday, 13 August, 2019 13:17, Jose Isaias Cabrera
> wrote:
>
> >James K. Lowden, on Tuesday, August 13, 2019 12:31 PM, wrote...
>
> >> On Mon, 12 Aug 2019 14:14:08 -0600 "Keith Medcalf", on
>
> >>> Perhaps I am just lazy but I see no point in engaging in extra
> >>> work for no advantage
>
> >> bool
> >> is_true (bool tf) {
> >> if (tf == true) {
> >> return true;
> >> }
> >> return false;
> >> }
>
> >Completely, completely off the subject, but since I see this code
> >here, and I have always wanted to ask this...
>
> >When I started programming, back in 1982, my teachers taught me to
> >match my end bracket to the same column where the beginning bracket
> >was. And they explained the whole theory behind it, which I think
> >it's true, to today. For example the above code, I would have
> >written it this way:'
>
> >bool is_true (bool tf)
> >{
> >if (tf == true)
> >{
> >return true;
> >}
> >return false;
> >}
>
> >Where, the brackets, begins/ends, would match the same column. When
> >did this ideology change? I see all of you smart programmers using
> >this non-column matching behavior, and I ask myself why? Thoughts?
> >Or not. :-) Thanks.
>
> It is a matter of taste I suppose, since there are numerous bits of
> software which can prettify various languages to a number of different
> formats. The primary reason I have heard putting the opening brace on the
> same line is that it takes less space on the screen, and after all we can
> only afford 5 line monitors, am-I-right?
>
> Personally I like the format where the braces line up with the start of
> the statement that they belong to and appear on a line by themselves, and
> the contained block is indented. Then again I can afford an absolutely
> humongous monitor that can display about 50 lines per page.
>
> Some people are severely allergic to white-space and so eliminate every
> non-required space/tab character all line-feeds/carriage-returns that are
> not within a quoted string and write their software as one big never-ending
> single line of code 40 miles long.
>
> There are also some wierd formats that some seem to like as well where
> they half-indent the braces and other such malarky.
>
> It is all a matter of taste and what you can see easily. I also tend to
> use blocks around code that technically does not need them (as in the above
> example) because it makes it easier to see what is going on -- the visual
> appearance matches the parse tree generated by the compiler as it were.
> Only the folks that do not use blocks obviously are struck by decades old
> code editing errors that they did not intend (and we have had a few of
> those in the last couple of years where the "visual depiction" did not
> match the "computer generated parse tree" ...
>
> --
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Programming methodology (was DEF CON (wasL A license plate of NULL))
On Tuesday, 13 August, 2019 13:17, Jose Isaias Cabrera
wrote:
>James K. Lowden, on Tuesday, August 13, 2019 12:31 PM, wrote...
>> On Mon, 12 Aug 2019 14:14:08 -0600 "Keith Medcalf", on
>>> Perhaps I am just lazy but I see no point in engaging in extra
>>> work for no advantage
>> bool
>> is_true (bool tf) {
>> if (tf == true) {
>> return true;
>> }
>> return false;
>> }
>Completely, completely off the subject, but since I see this code
>here, and I have always wanted to ask this...
>When I started programming, back in 1982, my teachers taught me to
>match my end bracket to the same column where the beginning bracket
>was. And they explained the whole theory behind it, which I think
>it's true, to today. For example the above code, I would have
>written it this way:'
>bool is_true (bool tf)
>{
>if (tf == true)
>{
>return true;
>}
>return false;
>}
>Where, the brackets, begins/ends, would match the same column. When
>did this ideology change? I see all of you smart programmers using
>this non-column matching behavior, and I ask myself why? Thoughts?
>Or not. :-) Thanks.
It is a matter of taste I suppose, since there are numerous bits of software
which can prettify various languages to a number of different formats. The
primary reason I have heard putting the opening brace on the same line is that
it takes less space on the screen, and after all we can only afford 5 line
monitors, am-I-right?
Personally I like the format where the braces line up with the start of the
statement that they belong to and appear on a line by themselves, and the
contained block is indented. Then again I can afford an absolutely humongous
monitor that can display about 50 lines per page.
Some people are severely allergic to white-space and so eliminate every
non-required space/tab character all line-feeds/carriage-returns that are not
within a quoted string and write their software as one big never-ending single
line of code 40 miles long.
There are also some wierd formats that some seem to like as well where they
half-indent the braces and other such malarky.
It is all a matter of taste and what you can see easily. I also tend to use
blocks around code that technically does not need them (as in the above
example) because it makes it easier to see what is going on -- the visual
appearance matches the parse tree generated by the compiler as it were. Only
the folks that do not use blocks obviously are struck by decades old code
editing errors that they did not intend (and we have had a few of those in the
last couple of years where the "visual depiction" did not match the "computer
generated parse tree" ...
--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a
lot about anticipated traffic volume.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Programming methodology (was DEF CON (wasL A license plate of NULL))
On Aug 13, 2019, at 1:16 PM, Jose Isaias Cabrera wrote: > > I see all of you smart programmers using this non-column matching behavior, > and I ask myself why? Thoughts? Or not. :-) It started in the days of real terminals, where the extra line was one of the 24-ish you got on a glass tty or it cost you a whole line on real paper on a traditional tty. Today, you’re probably running your text editor windows 60-80 lines high, so the extra line might not seem like much of cost, proportionately speaking. But, the more code you see on screen, the more context you have in front of you, so the less paging around through the file you have to do to maintain your mental model of what the program is doing. Out of sight, out of mind. As for alignment, every programmer’s text editor worth the name going back at least to vi (1980!) has some way of matching braces, no matter what column they’re in. Now that all programmer’s text editors worth the name have copied Emacs’ flash-matching feature, you no longer even have to hit a command key to do the match. There is no longer any reason to be unsure whether your braces are properly matched. Aligned braces are not only unnecessary in any curly-brace language I’m aware of, they carry cost you might not be willing to pay. Beyond that, you get into matters of style, rather than matters of pragmatic truth, which is not only off topic, it’s usually unproductive to argue over. Pick one style per project and stick to it. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
