Do you guys drop the S from your variable names? I am constantly in a dilemma as to what makes more sense.

For example a SQL Table:

Books
----------
BookID
BookName
....
---------

OR

Book
---------
BookID
BookName
.....
---------

Or even in a language like C# or JavaScript:

const BOOKS
var books
let books

or

const BOOK
var book
let book

Even if you have multiple items in that variable/table it seems very redundant to ever have the s.

What do you guys think? Any input appreciated!

Happy coding!

db

table: books
class: book
Fields: id, type, relation_id

PSR, naming conventions, ...

iow, I cringe on your database naming example..

var book = new Book()
var books = new List<book>()

@xewl but is it not redundant to have it like that in the DB?

Does it not make sense to have no S?

@ganjaman
books = Book::search() return Collection

Oh well, :'D

@Archeelux your queries should be fixed then.. just be explicit on which "table.field" when you join or select, instead of scrutinizing your table fields making everything unclear and ultra long in the end..

@xewl what the fuck is that syntax

@ganjaman pseudo? :v

@xewl if your brain works like that then im really worried you might be a psychopath

@ganjaman Oh, I have no worries, in that case lol...

I'll format;

class Book extends WhateverEloquentOrModel { .. }

$booksNeeded = (new Book)::filter(['in_wishlist'=>true,'user'=>Session::id()]);

Symfony/laravel whatever I guess

In the long run, it doesn't matter what convention you use, just be consistent.

If you start with singular names (like Book), stick with it. Primary key fields prefixed with the table name and ID (BookID), use that pattern everywhere. Avoid, at all costs, the temptation of letting users (and other devs) 'bully' you into changing it.

Why? Because no matter what convention you use, there will be many that will 'Monday-Morning Quarterback' your choices. Be able to proudly say "Yea, my naming sucks, but at least it sucks consistently."

Good luck.

@PaperTrail I do agree with the mindset of not letting others tell you what to do. Though, I do cringe, as I know how BookID, and shit turns out in code after 5 years in a project x) Oh well.

I prefer the Rails way.
Tables are plural, models are singular.

Book.create(title: "ANSI C", ...)
Book.first.title
#=> "ANSI C"
Book.first.title.to_sql
#=> "select title from books where id = 0"

The table holds rows of books.
The model describes a single book, and allows interacting with it. (As well as collections of books, but that clouds the example.)

@Archeelux oh, and I actually wouldn't care a whole lot if you'd do table names like book or product, though, since it's a collection of rows, I'd say it's more logical to use the plural.

"productAttributes" (or preferably "product_attributes") is another example I use though.

Single book will be :
Book(id,name,...)
Collection of Book will be :
Books [ ]

Same goes for DB, you can map Objects to Relations like Books table is going to hold Book entities with id,name,....

Simple : )

Table is analogous to a template like how a class is. So singular words

Think of joins. It will go like this

JOIN XYZ ON BOOK.XYZ

Which makes more sense because we think in terms of a single comparison, even though it's technically an aggregate comparison.

Also depends on your frameworks or ORM though... Some allow you to skip a lot of manual work when defining relationships as long as you follow their rules

@k33da I learn java, that way is correct

I use plural table names and my entities match my table names so they are plural as well just for consistency, but I recognize the "correctness" of singular class names when working one-on-one with an object.

The question is old.

I agree that you should stick and never change a naming system.

(@papertrail is right here)

The funny part is that you can argue in many ways...

I prefer singular wording for everything.

Reasoning? Stop overthinking....

There is just one thing you should avoid: mixing naming schemes (lower case, kebab case, snake case....) and the other is having ambiguous / common names.

Eg name the primary key ID field with a table prefix (book_id instead of ID) - debugging of complex queries is way easier.

Other example: naming a field datetime / user / enabled or something like that...

created_at / created_by / is_active might be better...

A table holds many records of the same type, so it's more natural to use the plural form when naming it (i.e 'books').

However, the columns refer to a single record, so you'd call the id column eg 'book_id', not 'books_id'.

As others have said, consistency is the most important thing, so if you're hungarian and want to call it 'tblBook' then by all means

Only in tables and lists of entities of those tables, the single entity without s

Thank you all for your feedback!

Easy: name it to what it represents. For db tables,.it's a matter of preference. I prefer singular, so Book it'll be. Why? Because it represents the data for a book entities. However, on might add: yeah so it stores books! Why not name it Books? As said, matter of preference.

But for code? Well, that's clear. 1 single instance? Name it singular, so var book = new Book(). It can hold more than one? books it'll be.